Skip to content

Web security

Content Security Policy: assess and roll out CSP

Plan Content Security Policy around real browser dependencies, distinguish report-only from enforcement, and retest scripts, frames, and checkout flows.

By BugSnaps · Updated

Direct answer

Content Security Policy (CSP) tells a browser which sources and behaviors a page permits. Assess the policy against the page's real dependencies, observe violations, and test enforcement. A report-only policy provides visibility but does not block the reported behavior.

Inventory the page's dependencies

List scripts, styles, images, frames, forms, and outbound browser connections used by representative journeys. Separate public marketing pages from signed-in tools. A payment integration may need permissions that should not be copied to every route.

  • Include sign-in, checkout, exports, and embedded widgets.
  • Record exact dependency origins rather than broad wildcards.
  • Identify inline code and the framework's CSP support.

Distinguish observation from enforcement

Content-Security-Policy-Report-Only records violations without enforcing the policy. It can help find missing legitimate dependencies during rollout. Keep that state visible in the assessment so an observation-only configuration is not reported as a blocking control.

Reference: OWASP Content Security Policy Cheat Sheet.

Evaluate the policy's actual restrictions

A long policy can still allow broad script execution. Review source allowances, inline script handling, framing, and form destinations against the application's risk. CSP complements safe rendering; it should not become the reason to leave unsafe HTML insertion unaddressed.

  • Check both the browser console and the served policy header.
  • Verify which directives protect the action being assessed.
  • Keep expected violations separate from successful blocking evidence.

Reference: OWASP Content Security Policy Cheat Sheet.

Roll out and verify a complete journey

After enabling enforcement, run the product's normal browser journeys and inspect blocked requests. Tighten route policies gradually when dependencies differ. Retain a known-good configuration so a failed rollout can be recovered without removing every restriction.

Assessment limits

CSP depends on browser support and the policy actually served. Report-only mode is not prevention. CSP cannot establish server-side access control, and broad allowances can reduce its protection even when the header is present.

Frequently asked questions

Does report-only CSP stop XSS?

Report-only mode does not enforce the policy. It supplies violation information for assessment and rollout. Blocking requires an enforced policy, alongside safe application rendering.

Should every page share one CSP?

Only when their dependency and behavior requirements match. A narrow policy for a static page may differ from one supporting a signed-in application or payment provider.

Is having a CSP header enough?

No. Review the directives, allowed sources, and browser behavior. A permissive policy can be present while offering little protection for the action under review.

Primary sources and further reading

These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.

Apply the guide to your own application.

Start with an authorized target, known test data, and a clear scope. Use the report's evidence and coverage limits to decide which checks need further review.

Open MyPentest