Content Security Policy
Content Security Policy, or CSP, is an HTTP rule for browser content. It limits which files may load and which scripts may run.
Another example
A banking SPA starts with `Content-Security-Policy-Report-Only` and removes inline handlers. It then enforces `script-src 'nonce-r4…' 'strict-dynamic'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'`. Every response gets a new, hard-to-guess nonce. Sampled violation reports do not record customer URLs.
Main parts
- 01Policy delivery
- 02Fetch and document directives
- 03Violation reporting and rollout
Use it when
Use a tested, strict CSP as an extra defense, preferably with nonces or hashes. Watch reports before turning a changed policy on fully.
Do not use it when
Do not treat wide `*` or `unsafe-inline` rules as strong security or reuse guessable nonces. CSP does not replace normal XSS prevention.
Name used in code
Content-Security-Policy response header with nonces/hashes and restrictive directives Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Content Security Policy for this system while keeping data correct, secure, and easy to operate. User context: A banking SPA starts with `Content-Security-Policy-Report-Only` and removes inline handlers. It then enforces `script-src 'nonce-r4…' 'strict-dynamic'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'`. Every response gets a new, hard-to-guess nonce. Sampled violation reports do not record customer URLs. Technical concept or control: Content Security Policy. Why it fits: Use a tested, strict CSP as an extra defense, preferably with nonces or hashes. Watch reports before turning a changed policy on fully. Do not use it when: Do not treat wide `*` or `unsafe-inline` rules as strong security or reuse guessable nonces. CSP does not replace normal XSS prevention. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): A formal document may still be a draft, release candidate, or final version. Check its status and browser or platform support. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Content Security Policy. Definition: Content Security Policy, or CSP, is an HTTP rule for browser content. It limits which files may load and which scripts may run. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.