CSP directives are the individual rules inside a Content Security Policy header or meta tag. They specify which sources are allowed for scripts, styles, images, frames and other resource types, and they shape browser-side controls against injection and content loading abuse.
What CSP Directives Do
CSP directives are the policy primitives that make Content Security Policy actionable. Each directive narrows a browser’s loading or execution choices for a specific resource class, such as scripts, styles, frames, images, fonts, connections, or embedded objects.
That specificity is what gives CSP its defensive value. Instead of treating the whole page as trusted, directives let you define separate allow rules for each sink or fetch path, reducing the chance that one injection flaw becomes a full-page execution problem.
Why Directive Granularity Matters
Different directives protect different browser behaviours, and the gaps between them matter. A policy that is strong for scripts may still leave room for clickjacking, untrusted framing, inline style abuse, or unexpected data exfiltration if the other directives are loose or missing.
Modern CSP use is therefore less about having a single policy string and more about understanding how individual directives interact. For example, script-src can constrain executable JavaScript, while frame-ancestors helps control who may embed the page, and connect-src influences outbound browser requests.
How CSP Directives Reduce Injection Exposure
The main security job of CSP directives is to make browser-side injection harder to turn into code execution or unauthorized content loading. When sources are tightly scoped, an attacker who can influence HTML, template output, or a reflected parameter has fewer paths to load malicious scripts or pivot through hostile frames and remote assets.
Well-chosen directives also support safer hardening patterns such as nonces, hashes, and Trusted Types. NHIMG’s Content Security Policy Guide covers how strict policies, report-only rollout, and frame controls fit together in practice, while Trusted Types and DOM XSS Prevention Guide explains the complementary browser controls that help close DOM XSS sinks.
Common Failure Modes in Real Policies
Directive design fails when teams assume that one permissive rule is harmless because the page still “has CSP.” Wildcards, broad host lists, fallback directives, and legacy exceptions can quietly reintroduce the very injection and content-loading paths the policy was meant to block.
Another common failure is uneven coverage. A policy may protect script execution while leaving frames, form targets, or browser connections too open. Iframe Sandboxing and srcdoc Security Guide is useful here because frame-related controls often need to be considered alongside CSP rather than as an afterthought.
Risk and Threat Considerations
Weak or incomplete CSP directives can turn a minor injection issue into script execution, session theft, content spoofing, or data exfiltration. The risk is highest when the policy is present but diluted by broad allowances, because defenders may overestimate how much control the browser is actually enforcing.
Failure mechanism: Attackers exploit any directive that still permits attacker-controlled sources, then chain that permission into script loading, frame abuse, or outbound requests that bypass the intended trust boundary.
Impact: The page may execute untrusted code, expose tokens or sensitive data, or load deceptive content that undermines user trust and browser-side containment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V14 — Data Protection | CSP directives constrain browser content loading and injection exposure. |
| V15 — Secure Coding and Architecture | Directive choice is part of secure web architecture and defense-in-depth. | |
| Recommendation — Use V14 to require restrictive browser-side content policies that reduce injection and data exposure. Apply V15 to design page-level controls that separate trusted from untrusted content paths. | ||
| NIST SP 800-53 Rev 5 | SC-18 — Mobile Code | CSP directives limit execution and sourcing of browser-delivered code. |
| SC-34 — Non-Modifiable Executable Content | CSP can enforce constraints that prevent unauthorized executable content from running. | |
| SI-10 — Information Input Validation | CSP complements validation by limiting exploitability of injected markup or script. | |
| Recommendation — Use SC-18 to restrict active content sources and reduce code-loading abuse. Apply SC-34 to prevent unauthorized executable content from being accepted or run. Use SI-10 with CSP so untrusted input is validated before it can influence browser behavior. | ||
| CIS Controls v8 | 16 — Application Software Security | CSP directives are a web application hardening control against injection. |
| 14 — Security Awareness and Skills Training | Teams need to understand how browser-side controls and injection abuse interact. | |
| Recommendation — Build and test CSP into application security requirements and release checks. Train developers to recognize CSP weaknesses and to avoid unsafe exceptions. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | CSP helps protect browser-delivered data from exposure through injected content paths. |
| PR.PS-03 — Third-Party Software, Services, and Components are Managed | CSP often governs which external scripts and resources the browser may load. | |
| PR.AA-05 — Network Access is Protected | Directive scoping can constrain browser-originated connections and embedded access paths. | |
| Recommendation — Strengthen browser-content restrictions so sensitive data is less likely to be exposed through injection. Manage approved third-party sources tightly before allowing them in CSP. Use access-scoping rules to limit what the browser may connect to or embed. | ||
Practitioner Guidance
Governance implication: Treat each directive as a separate security decision, not a stylistic header choice. The useful question is not whether CSP exists, but whether each resource class has an intentionally narrow rule set that matches the page’s real behaviour.
What to watch for: Policies that rely on broad host allowlists, long exception chains, or inconsistent enforcement modes usually deserve review first. If a directive is only present because it was copied from a template, it often carries more residual risk than protection.
Practitioner takeaway: A good CSP is specific, tested, and maintained over time, because the security value comes from the exact directives you keep tight, not from the header alone.
Related resources from NHI Mgmt Group
- How should security teams operationalise emergency directives faster without rebuilding their stack?
- Why do Angular applications still need CSP if they already use framework protections?
- How can security teams tell whether their CSP is actually working?
- When should teams choose response headers instead of meta tag CSP?