Correction guide

Content Security Policy: prepare a suitable CSP

By Antoine Le Louët · Estimated reading : 6 min · References

A CSP limits the sources and behaviours the browser permits. Deployment starts with an inventory of your page, not a universal configuration.

What CSP protects

Content Security Policy reduces some risks of injected code execution. It complements output escaping, input validation and vulnerability fixes; it does not guarantee freedom from XSS or certify compliance.

An HTTP header applies from the document response. A meta tag has limitations: no Report-Only mode, no frame-ancestors directive, and no retroactive protection for content already processed. Prefer the header.

Inventory before blocking

In a test environment, exercise sign-in, forms, payment, integrations, fonts, images and scripts. Record the origins actually needed and inline scripts/styles. Include consent and signed-in variants.

  1. Build a minimal list for each resource type. Avoid broad wildcards and global https: allowances for convenience.
  2. Identify what sets headers: application, server or CDN. Multiple enforced policies apply together; adding another cannot relax the first.
  3. Choose unpredictable nonces renewed per response, or hashes for controlled static scripts, when inline content is required.

Observe with Report-Only

For a static test page with same-origin resources, this example observes violations without enforcing blocks. Adapt every directive to your inventory. Violations appear in the console; no reporting collector is configured here.

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'
  1. Reload and exercise every journey; read the affected directive and resource in violations.
  2. Distinguish expected resources, injection and extension noise. Do not allow an origin simply to dismiss a message.
  3. If you add a collector, control access, volume and retention: reports may contain sensitive URLs.

Enforce, then check for regressions

Once journeys work, serve the tailored policy under Content-Security-Policy. Monitor errors and keep a procedure to restore the previous policy. An already enforced CSP stays active when you add Report-Only.

Avoid unsafe-inline in script-src: it permits inline scripts in policies where it is effective. A nonce requires random server generation and a matching attribute on each allowed script; never copy a fixed example nonce. Check HTML caching too.

What the Argos check establishes

The http.security.csp check reads the final Content-Security-Policy header and recognises a restrictive subset of script-src, or default-src when absent: self, none, nonces, hashes and explicit HTTPS origins. An unrecognised policy needs review; this heuristic cannot prove freedom from XSS. Report-Only does not satisfy this check.

External modules may add findings when available. Rerun the audit after functional tests; inspect evidence and report coverage. HSTS addresses HTTPS transport and has a different deployment process.

Official references

References checked on 16 October 2026. Adapt and test the examples within your own scope.

Verify your fix

After your tests, rerun an audit of the same public URL and compare available findings.

Run a new audit