---
{
  "title": "Content Security Policy (CSP)",
  "summary": "Content Security Policy lets a site tell the browser which resources and execution patterns it permits.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Content Security Policy",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Content Security Policy lets a site tell the browser which resources and execution patterns it permits. A restrictive script policy can reduce the impact of some script injection flaws. CSP is a layer of protection that must fit the application's actual resource loading and browser behavior.

## A practical example

A team introduces a report-only policy, identifies legitimate scripts, and moves toward a nonce-based policy. It verifies policy delivery on document responses and checks that a new third-party widget does not require broad exceptions.

## What to check

Inventory scripts and resource origins, generate unpredictable nonces for each response when used, and review violation reports. Test critical workflows before enforcing a stricter policy.

## A common pitfall

A policy that broadly permits inline scripts or arbitrary origins can offer little protection. CSP also does not replace fixing injection or unsafe DOM operations.

## Think it through

Does a report-only policy block an injected script?

**Answer:** No. It reports policy violations so the team can evaluate a policy before enforcement.

## A policy is an executable contract

A fictional learner portal loads its own application code, an analytics script, and a payment frame. A useful CSP describes those needs deliberately. Start by asking which code must execute and which origins must supply resources, rather than copying a policy from an unrelated website. Different directives govern scripts, images, frames, and other destinations.

A nonce-based approach requires coordination between the response header and the scripts authorized in that response. The nonce should be generated appropriately for the response and should not become a fixed identifier copied across the application. Caches and server-side rendering can complicate that relationship, so review the actual delivered document rather than just a template.

Reporting helps identify breakage and unexpected resource use, but reports are untrusted operational data. They may be noisy, contain sensitive URLs, or arrive from manipulated clients. Set appropriate collection limits and retention. A clean reporting period is useful evidence for deployment readiness, not proof that every injection flaw has disappeared.

## Introduce restrictions with a rollback plan

For the learner portal, inventory the normal login, lesson, payment, and support workflows. Test a proposed policy in report-only mode, investigate necessary resources, and remove unnecessary exceptions before enforcement. Define who owns each exception and when it should be reviewed. A third-party widget should not automatically justify allowing scripts from any origin.

After enforcement, verify both an expected script and a harmless deliberately blocked test resource in a controlled environment. Review error documents and alternate routes too. The policy's value depends on consistent delivery and meaningful restrictions. Correct output handling remains the primary repair for injection, while CSP can make some failures harder to exploit and unexpected behavior easier to notice.

## Related concepts

- [[xss]]
- [[output-encoding]]
- [[third-party-javascript]]