CSP

Prompting an agent to fix CSP safely

Content Security Policy is powerful and easy to over-tighten. Give your coding agent evidence, constraints, and a verification loop.

1 August 2026 · 5 min read

A Content Security Policy finding is the clearest example of where AI help is useful but needs rails. CSP is not one setting. It is a description of every script, style, image, frame and network connection the browser should allow — which means a careless fix breaks things a build will never catch.

Give the agent your real integrations

A good prompt names the current finding and what the app genuinely loads. For example: Add a conservative CSP for this Next.js app. It uses no third-party scripts, no remote images, and Stripe Checkout only redirects off-site. Keep inline SVG data URLs working. Run the build afterwards.

That gives the agent something important: permission to preserve legitimate behaviour. Without it, an agent may produce a policy that looks secure and blocks fonts, styles, images, or a checkout flow.

The goal is the true policy, not the longest one

A maximal policy copied from elsewhere describes someone else's application. It will either break yours or be quietly loosened until it means nothing.

Expect trade-offs, and expect to name them. A framework that emits inline scripts may need unsafe-inline unless you adopt per-request nonces, and nonces have their own cost — they can force pages to render dynamically that you wanted static. That is a real decision, not a detail to delegate.

Verify in a browser, not just a build

CSP failures appear in the browser console and as broken assets. A passing build is necessary and nowhere near sufficient for this class of fix.

Walk the real flows afterwards: the page that loads fonts, the one that renders images, and any redirect to a payment provider. Those are where an over-tight policy shows up first.

Common questions

What is a safe starting CSP?

Something close to default-src 'self' with object-src 'none' and frame-ancestors 'none', then widen only where your app genuinely needs it. Starting narrow and loosening is far safer than starting wide and hoping to tighten later.

Why does my framework need unsafe-inline?

Many frameworks inject inline bootstrap or hydration scripts. Removing unsafe-inline usually means adopting per-request nonces, which can prevent pages from being statically prerendered — a genuine trade-off worth making deliberately.

Will a CSP break my analytics or payment provider?

It can, if the policy does not allow them. This is why the prompt should list every third-party service the app actually uses before the policy is written.