Cusdis is one of those tools that looks deceptively simple from a CSP perspective. It’s “just comments,” until you wire it up and realize you’ve now introduced third-party scripts, API calls, maybe an iframe, maybe your own deployment, and a bunch of policy decisions you’ll need to defend later.

If you care about keeping a tight Content Security Policy, Cusdis is actually pretty manageable. Better than many ad-heavy comment systems, honestly. But the right CSP depends heavily on how you use it:

  1. Hosted Cusdis via script
  2. Hosted Cusdis via iframe
  3. Self-hosted Cusdis

Those choices have very different security tradeoffs.

The short version

If I had to rank them for CSP sanity:

  • Best security/control: self-hosted Cusdis
  • Best simplicity: hosted iframe
  • Most common but slightly messier: hosted script embed

The real question is whether you want convenience or control.

What Cusdis usually needs

At a minimum, Cusdis typically needs:

  • a script source for the embed JS
  • a connect source for its API
  • sometimes frame permissions, depending on embed method
  • potentially style allowances, depending on how the widget renders

That means your CSP usually changes in one or more of:

  • script-src
  • connect-src
  • frame-src
  • possibly style-src

If you’re starting from a strict baseline, test before shipping. I usually run a candidate policy through browser devtools and then verify the final headers with HeaderTest, especially when a page mixes analytics, consent tooling, and comments. Real-world CSPs get noisy fast.

For example, a real CSP from headertest.com looks like this:

content-security-policy:
  default-src 'self' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com;
  script-src 'self' 'nonce-NDQ5YmQ0NjAtZGU3YS00ZGMxLTk3NDgtZjFmZGFlODAwYzgy' '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'

That’s a good reminder that comments are rarely the only thing in your policy. Every extra integration competes for space in your CSP budget.

Option 1: Hosted Cusdis via script embed

This is the setup most developers reach for first. You drop in the Cusdis script, add a target element, and let it render the widget.

A typical policy might look something like this:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cusdis.com;
  connect-src 'self' https://cusdis.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  frame-ancestors 'self';
  base-uri 'self';
  object-src 'none';

And the embed might look like:

<div id="cusdis_thread"
     data-host="https://cusdis.com"
     data-app-id="YOUR_APP_ID"
     data-page-id="{{ .RelPermalink }}"
     data-page-url="{{ .Permalink }}"
     data-page-title="{{ .Title }}"></div>

<script async defer src="https://cusdis.com/js/cusdis.es.js"></script>

Pros

  • Easy to set up
  • No infrastructure to run
  • Fastest path to working comments
  • Usually only needs a couple of CSP allowances

Cons

  • You trust a third-party script
  • If Cusdis changes how the embed works, your CSP may need updates
  • You may end up allowing more than you’d like in script-src or style-src
  • If you’re aiming for a very strict nonce/hash-only script policy, third-party embeds are annoying

My take

This is fine for most sites. If your current CSP already allows a few external services, adding one more for comments is not some catastrophic failure. But if you’ve spent time building a clean script-src with nonces and strict-dynamic, adding a remote widget can feel like backsliding.

If you need ready-made patterns for tightening policies around third-party widgets, csp-examples.com is useful for sanity checks.

Option 2: Hosted Cusdis via iframe

This is the cleaner isolation model. Instead of executing the comment app inside your page context, you embed it in an iframe.

A policy for that often looks more like this:

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

Example embed:

<iframe
  src="https://cusdis.com/widget?appId=YOUR_APP_ID&pageId=post-123"
  style="width:100%; min-height: 600px; border:0;"
  loading="lazy"
  title="Comments">
</iframe>

Pros

  • Much better isolation
  • Your page doesn’t need to execute Cusdis JavaScript directly
  • Usually means a tighter script-src
  • Lower risk that third-party script behavior affects your main document

Cons

  • You still trust the third-party origin, just in a different way
  • Styling and responsive behavior can be clunkier
  • Cross-frame communication can complicate things if you want fancy integrations
  • Some features may be less ergonomic than the standard script embed

My take

From a CSP perspective, I like this more than the script embed. An iframe keeps the blast radius smaller. If the comments system is compromised, I’d rather it be fenced into a frame than living in my page’s JS environment.

The downside is developer experience. iframe integrations are often slightly more brittle and less customizable. If your design team cares deeply about seamless visual integration, they may hate this option.

Option 3: Self-hosted Cusdis

This is where CSP gets nicest, assuming you’re willing to own the deployment.

If you host Cusdis on a subdomain you control, like comments.example.com, you can keep your policy much tighter and avoid depending on the public hosted service.

Example policy for a main site embedding your own comments service:

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

If your app server renders the embed script locally, you can tighten it even further:

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

Pros

  • Best control
  • Better privacy story
  • Easier to align with strict CSP goals
  • Lower third-party supply chain risk
  • Easier to pin behavior to your own deployment choices

Cons

  • You now run the service
  • Need to handle updates, backups, uptime, abuse, spam, and maintenance
  • Misconfiguring your own deployment can be worse than trusting a competent hosted vendor
  • More moving parts than “paste this script”

My take

If you already self-host infrastructure and you care about CSP, this is the best option. No contest. You get to decide the architecture, the allowed origins, and how much trust you extend.

If you’re a solo dev who barely wants to manage DNS, skip it. Security controls that you won’t maintain are fake controls.

Pros and cons side by side

Hosted script embed

Pros

  • quickest setup
  • good customization
  • common docs/examples

Cons

  • weakest CSP posture of the three
  • third-party JS in page context
  • often pushes you toward looser directives

Hosted iframe

Pros

  • strongest isolation without self-hosting
  • cleaner script-src
  • easier to reason about risk

Cons

  • less elegant integration
  • may limit customization
  • still depends on third-party availability

Self-hosted

Pros

  • best CSP compatibility
  • strongest control and privacy
  • reduces external trust

Cons

  • operational burden
  • maintenance and abuse handling
  • more setup work

Practical recommendation

Here’s what I’d actually recommend:

Use hosted iframe if:

  • you want low maintenance
  • you care about CSP
  • you can tolerate a little UI awkwardness

Use hosted script embed if:

  • you want the easiest supported integration
  • your CSP is already moderately permissive
  • you accept third-party script risk

Use self-hosted Cusdis if:

  • you run a serious production site
  • you already manage your own infra
  • you want a strict, defensible CSP posture

A few CSP gotchas with Cusdis

Don’t start with *

I still see people solve widget breakage by throwing https: or * into half their directives. That’s not a policy, that’s giving up.

Watch style-src

Some embeds need inline styles or inject styles dynamically. If you can avoid 'unsafe-inline', do it. If you can’t, at least isolate the reason and document it.

Be careful with frame-ancestors

This controls who can embed your page, not what you can embed. Developers mix this up constantly.

Prefer explicit origins

If you know the exact Cusdis host you use, allow that exact host. Avoid broad wildcards unless you have a real reason.

My default choice

If I’m building a content site and want comments without turning my CSP into a junk drawer, I’d pick:

  1. self-hosted Cusdis if I already have the ops muscle
  2. hosted iframe if I want convenience with decent isolation
  3. hosted script embed only when seamless integration matters more than CSP neatness

That’s the tradeoff. There isn’t a magic policy that makes third-party comments free of risk. There’s only choosing where the risk lives: in your page, in a frame, or in your own infrastructure.