CSP for Commento: Pros, Cons, and Policy Examples

If you embed Commento, your CSP gets more interesting fast.

Comment systems are one of those features that look harmless in product planning and then quietly punch holes in an otherwise tight policy. You add one script, maybe an iframe, maybe an API endpoint, and suddenly your neat default-src 'self' turns into a pile of exceptions nobody wants to touch six months later.

Commento is still one of the cleaner options compared to heavier third-party widgets. That’s the good news. The less-good news: the “right” CSP for Commento depends heavily on how you deploy it.

There are really two common setups:

1. Self-hosted Commento on your own domain or a controlled subdomain
2. Hosted Commento from a third-party Commento origin

Those two choices change your CSP quite a bit. If you care about keeping a strict policy, self-hosting usually wins.

The short version

If I had to give the blunt recommendation:

• Best for CSP hygiene: self-host Commento on a dedicated subdomain you control
• Best for convenience: use hosted Commento and allow only the specific origins it needs
• Worst option: throw broad wildcards into script-src, frame-src, and connect-src just to “make comments work”

That last one is how CSP slowly becomes security theater.

Why Commento affects CSP

A Commento embed usually needs some combination of:

• a JavaScript file
• API requests back to the Commento server
• sometimes styles
• sometimes frames, depending on integration details
• form submissions for posting comments

So the directives you’ll usually touch are:

• script-src
• connect-src
• style-src
• img-src
• frame-src
• form-action

If you’re doing CSP properly, you should avoid relaxing default-src just to accommodate one feature.

For reference, here’s a real-world CSP header from HeaderTest:

content-security-policy: default-src 'self' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com; script-src 'self' 'nonce-NDIzODQ0YWEtMjE2Zi00MmI4LThhMzEtNWIxNTQ0ODgwYzA2' 'strict-dynamic' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com; style-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://*.cookiebot.com https://consent.cookiebot.com; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.headertest.com https://tallycdn.com https://or.headertest.com wss://or.headertest.com https://*.google-analytics.com https://*.googletagmanager.com https://*.cookiebot.com; frame-src 'self' https://consentcdn.cookiebot.com; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; object-src 'none'

I like this example because it shows what a mature policy looks like in practice: specific directives, limited origins, and no lazy * everywhere. That’s the mindset you want when adding Commento.

Option 1: Self-hosted Commento

If you host Commento on something like comments.example.com, your main site CSP can stay pretty disciplined.

Example CSP

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://comments.example.com;
  connect-src 'self' https://comments.example.com;
  style-src 'self' https://comments.example.com;
  img-src 'self' data: https://comments.example.com;
  frame-src https://comments.example.com;
  form-action 'self' https://comments.example.com;
  base-uri 'self';
  object-src 'none';
  frame-ancestors 'self';

Depending on your embed method, you may not need all of these. Start strict, then trim or add based on actual violations.

Pros

1. Tightest CSP control

This is the big one. If Commento lives on infrastructure you control, you can whitelist a single known origin and move on.

That’s much better than trusting a vendor-owned domain that might change behavior later.

2. Easier to reason about risk

I trust my own subdomain more than some third-party service. That’s not paranoia; that’s basic blast-radius reduction.

If your app allows:

script-src 'self' https://comments.example.com

that’s a much smaller trust decision than allowing a shared third-party domain you don’t operate.

3. Better alignment with strict CSP patterns

If you’re already using nonces, hashes, or strict-dynamic, self-hosting fits nicely. You can keep your main script policy clean and avoid broad allowances.

4. Fewer surprises over time

Hosted SaaS tools love silently adding new endpoints, CDNs, analytics calls, or assets. Self-hosting doesn’t eliminate this entirely, but it cuts down the chance that your CSP breaks because somebody changed their frontend stack on a Tuesday.

Cons

1. Operational overhead

You have to run it, patch it, monitor it, and back it up. That’s real work.

2. You own the security of the comment service

If your Commento instance is misconfigured or outdated, that’s your problem now.

3. Subdomain trust still matters

If comments.example.com gets compromised, your CSP has already blessed it. Don’t pretend same-organization trust is risk-free.

A nice pattern here is to isolate it hard: separate deployment, separate cookies, no unnecessary shared auth.

Option 2: Hosted Commento

If you use a hosted Commento service, you’ll need to permit the service’s origin directly.

Example CSP

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://commento.example-host.com;
  connect-src 'self' https://commento.example-host.com;
  style-src 'self' https://commento.example-host.com;
  img-src 'self' data: https://commento.example-host.com;
  frame-src https://commento.example-host.com;
  form-action 'self' https://commento.example-host.com;
  base-uri 'self';
  object-src 'none';
  frame-ancestors 'self';

Replace the host with the actual Commento endpoint you use. Don’t guess, and don’t use wildcards unless the service genuinely requires them.

Pros

1. Fastest setup

Paste the embed code, add a few CSP allowances, done.

2. Less infrastructure to manage

No patching, no upgrades, no database babysitting.

3. Usually simpler for small teams

If comments are a side feature, hosted Commento may be the right tradeoff. Not every engineering team needs to self-host everything on principle.

Cons

1. Weaker trust boundary

You are explicitly trusting a third party in script-src and connect-src. That’s not automatically bad, but it is a real security decision.

2. Vendor changes can break your CSP

A new CDN, a different asset host, extra API endpoints — now your comments fail until you update your policy.

3. Temptation to over-broaden

This is the classic failure mode:

script-src 'self' https: 'unsafe-inline' 'unsafe-eval';
connect-src *;
frame-src *;

Yes, comments will probably work. Your CSP will also be mostly decorative.

Inline embed code: the annoying part

Some Commento integrations use inline bootstrapping code. If you copy-paste their snippet directly into HTML, you may be tempted to add 'unsafe-inline' to script-src.

I wouldn’t.

Use a nonce or move the bootstrap into an external script you host yourself.

Better approach with a nonce

<script nonce="{{ .CSPNonce }}">
  window.commentoConfig = {
    server: "https://comments.example.com"
  };
</script>
<script
  nonce="{{ .CSPNonce }}"
  src="https://comments.example.com/js/commento.js">
</script>

And then:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-rAnd0m123' https://comments.example.com;
  connect-src 'self' https://comments.example.com;
  style-src 'self' https://comments.example.com;
  img-src 'self' data: https://comments.example.com;
  base-uri 'self';
  object-src 'none';

If you already use strict-dynamic, be careful and test the loading chain. It can simplify things, but it can also confuse teams that don’t understand how trust propagates.

Pros and cons by CSP strictness

Here’s the practical comparison.

Self-hosted Commento + strict CSP

Pros

• Best security posture
• Minimal third-party trust
• Easier audit story
• Cleaner long-term policy

Cons

• More DevOps work
• More ownership burden

Hosted Commento + strict allowlist CSP

Pros

• Good balance of convenience and control
• Reasonable for most teams
• Still much better than permissive CSP

Cons

• You depend on vendor stability
• Policy maintenance may increase over time

Hosted Commento + permissive CSP

Pros

• Fastest way to stop CSP errors

Cons

• Barely worth having CSP
• Hard to review
• Easy to accumulate risky exceptions
• Future you will hate present you

My recommended policy shape

For most developer teams, I’d use this approach:

• Keep default-src 'self'
• Add Commento only to the directives it actually needs
• Prefer a dedicated subdomain if self-hosting
• Avoid 'unsafe-inline' in script-src
• Avoid wildcards
• Use Report-Only first before enforcing

Example baseline:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://comments.example.com;
  connect-src 'self' https://comments.example.com;
  style-src 'self' https://comments.example.com;
  img-src 'self' data: https://comments.example.com;
  form-action 'self' https://comments.example.com;
  base-uri 'self';
  object-src 'none';
  frame-ancestors 'none';
  report-to default-endpoint;
  report-uri /csp-report;

If you need ready-made patterns for different frameworks and deployment styles, csp-examples.com is a handy starting point.

What I’d choose

If comments matter to the product and you care about security maturity, I’d self-host Commento on a dedicated subdomain.

If comments are low-priority and the team is small, hosted Commento is fine — as long as you keep the CSP narrow and resist the usual “just allow everything from everywhere” shortcut.

That’s really the whole tradeoff:

• Self-hosted Commento gives you the best CSP story
• Hosted Commento gives you the best convenience story

Pick the one that matches your appetite for operational work. Just don’t pretend a bloated allowlist is harmless because “it’s only comments.” That’s exactly how good CSPs get watered down.