Content Security Policy or Execution Policy¶
Declarative policy — instantiates Data-Control Boundary Inertization
A declarative policy the runtime consults after parsing and before execution, naming which sources and channels may run and treating everything else as inert — so injected content that slips past other controls still has no authority to act.
Even a well-built boundary occasionally leaks; Content Security Policy or Execution Policy is the layer that assumes it will. It is a declarative rule set the runtime consults after content is parsed and before it is allowed to act, stating which sources, channels, and forms of execution are permitted — and treating everything else as inert by default. Its defining move is separating the authoritative channel from ambient content: only code arriving through a declared, trusted channel — a nonce'd script, an allowlisted origin, a signed binary — may execute, so injected content, bearing no such marker, simply never runs. It is defense in depth by design: not the control that stops injection, but the one that denies injected content any authority once it is present.
Example¶
A content site renders reader comments and also loads first-party and analytics scripts. Its pages carry a Content-Security-Policy that permits scripts only when they bear a per-response nonce the server issues to its own trusted scripts. A stored comment that contains an inline <script> reaches the browser — sanitization is the primary defense and can be imperfect — but the browser, consulting the policy, finds the inline script has no valid nonce and refuses to execute it. The comment's text still displays; its attempt to become code is verdicted "not permitted." The same page, without the policy, would depend entirely on every upstream control being flawless.
How it works¶
- Declare the trusted channels. The policy names the sources, origins, and markers that may execute; execution outside them is denied.
- Verdict at execution time. After the content is parsed and loaded, the runtime asks the policy whether this is permitted to run, independent of whether it looked benign.
- Deny by default. Anything not positively permitted — inline injection, an unlisted origin — is inert, so a control failure upstream does not automatically become code execution.
Tuning parameters¶
- Permitted-source breadth — a tight allowlist of origins and nonce'd scripts versus broad wildcards. Tighter denies more injected content but can break legitimate third-party integrations.
- Inline escape hatches — whether to allow inline execution (e.g.
unsafe-inline) for convenience. Allowing it is the single most common way a policy is quietly gutted. - Enforce vs. report-only — block violations, or only report them while tuning. Report-only surfaces breakage without protection; enforce protects but risks blocking legitimate content.
- Scope of the policy — how much of the surface (scripts, styles, frames, connections, form targets) the policy governs. Broader coverage closes more channels at more maintenance cost.
When it helps, and when it misleads¶
Its strength is precisely that it is a second line: it limits the damage of an injection the primary controls missed, which is the whole point of defense in depth, and it does so declaratively, without inspecting content for badness.[n1] Its failure modes are permissiveness and misplaced trust: a policy riddled with wildcards or inline exceptions gives the appearance of protection while permitting the very execution it should deny, and — the classic misuse — teams lean on the policy as a substitute for encoding and validation rather than a backstop, so when it is loosened for a business reason the primary hole is fully exposed. The discipline is deny-by-default, no blanket inline exceptions, and treating the policy as a net beneath other controls, never as the floor.
How it implements the components¶
channel_separation_boundary— the policy separates the authoritative execution channel (declared origins, nonce'd scripts) from ambient content, so only the former can act.post_parse_policy_verdict— after content is parsed and loaded, the policy renders the runtime verdict on whether it is permitted to execute.
It does not transform a value into an inert representation — that is Contextual Output Encoding — nor validate structure at the input boundary (Allowlisted Parser or Schema Validator), nor strip the process's ambient privileges (Least-Privilege Execution Context).
Related¶
- Instantiates: Data-Control Boundary Inertization — it is the runtime backstop that denies un-sanctioned content the authority to execute.
- Sibling mechanisms: Contextual Output Encoding · Least-Privilege Execution Context · Allowlisted Parser or Schema Validator · Capability-Scoped Tool Invocation · Injection Payload Regression Tests · Parameterized Interpreter Call · Structured Command Construction · Template or Markup Sandbox · Taint Tracking or Provenance Labeling · Rejection or Quarantine Queue
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: The policy declaratively names trusted execution sources and denies authority to everything not positively permitted, imposing a standing default-deny constraint on future content.
Nearest alternative: Control, Automation & Runtime — The runtime consults and enforces the policy for each execution, but the mechanism is explicitly the declarative permission rule rather than the enforcement engine.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Web and runtime security cohered declarative execution policies such as Content Security Policy that allow trusted channels and leave injected content inert by default.
Related originating lineages:
- Security Studies & Intelligence Analysis — Least-authority and allowlist practice supplies the adversarial trust-boundary rationale.
Review resolution: Web-security engineering cohered declarative source allowlists and execution restrictions; security is a genuine disciplinary lineage, and the method is specialized and established.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Defense in depth layers independent controls so that the failure of one does not breach the system; an execution policy is valuable precisely as a later layer, not a first one. The common way it fails is permissiveness — for instance allowing inline execution — which lets injected content satisfy the policy and defeats the layering. ↩