Working Web skill
Implement content security policy
Implement a staged Content Security Policy from an evidence-based resource inventory, with enforceable directives and safe rollout controls.
Build the policy from required behavior, not copied allowlists.
When to use
- Use for a new policy, a report-only policy ready for enforcement, or a policy weakened by third-party additions.
- Fix injection flaws independently; CSP is defense in depth, not permission to render unsafe input.
Procedure
- Inventory first-party and third-party scripts, styles, images, fonts, frames, workers, forms, media, manifests, and network destinations by route and user state.
- Remove obsolete dependencies and inline code before granting sources.
- Establish
default-src 'none', then add the narrowest required directives for each resource class. - Prefer per-response nonces or stable hashes for required inline code. Do not add
unsafe-inlineor broad wildcards to silence violations. - Constrain navigation and embedding with
base-uri,object-src,frame-ancestors,form-action, and relevant sandbox or permission controls. - Evaluate
strict-dynamic, Trusted Types, upgrade controls, and reporting against browser support and application architecture. - Deploy report-only to controlled users. Sample and redact reports so URLs or user data do not become a new privacy leak.
- Classify violations as required behavior, blocked attack, extension noise, browser variance, or application defect.
- Add automated header, nonce, route, browser, third-party failure, and injection tests.
- Enforce by route or traffic wave with violation, conversion, error, and support monitoring. Keep a versioned rollback that restores the last safe policy rather than removing CSP.
Failure plan
- If a vendor needs a broad source, isolate or replace it before widening the whole application.
- If enforcement breaks a critical route, revert to the last safe policy while preserving report evidence and fixing the missing dependency.
- Never include secrets, full query strings, or personal data in violation telemetry.
--- name: implement-content-security-policy category: web description: Implement a staged Content Security Policy from an evidence-based resource inventory, with enforceable directives and safe rollout controls. Use when reducing script, framing, injection, or data-exfiltration risk in a web application. --- # implement-content-security-policy Build the policy from required behavior, not copied allowlists. ## When to use - Use for a new policy, a report-only policy ready for enforcement, or a policy weakened by third-party additions. - Fix injection flaws independently; CSP is defense in depth, not permission to render unsafe input. ## Procedure 1. Inventory first-party and third-party scripts, styles, images, fonts, frames, workers, forms, media, manifests, and network destinations by route and user state. 2. Remove obsolete dependencies and inline code before granting sources. 3. Establish `default-src 'none'`, then add the narrowest required directives for each resource class. 4. Prefer per-response nonces or stable hashes for required inline code. Do not add `unsafe-inline` or broad wildcards to silence violations. 5. Constrain navigation and embedding with `base-uri`, `object-src`, `frame-ancestors`, `form-action`, and relevant sandbox or permission controls. 6. Evaluate `strict-dynamic`, Trusted Types, upgrade controls, and reporting against browser support and application architecture. 7. Deploy report-only to controlled users. Sample and redact reports so URLs or user data do not become a new privacy leak. 8. Classify violations as required behavior, blocked attack, extension noise, browser variance, or application defect. 9. Add automated header, nonce, route, browser, third-party failure, and injection tests. 10. Enforce by route or traffic wave with violation, conversion, error, and support monitoring. Keep a versioned rollback that restores the last safe policy rather than removing CSP. ## Failure plan - If a vendor needs a broad source, isolate or replace it before widening the whole application. - If enforcement breaks a critical route, revert to the last safe policy while preserving report evidence and fixing the missing dependency. - Never include secrets, full query strings, or personal data in violation telemetry. ## Done - A CSP inventory maps every allowed source and directive to an owner and required behavior - Browser and injection tests prove required resources work and unauthorized script, frame, form, and connection paths are blocked - A staged enforcement record captures violations, exceptions, monitoring, policy version, and safe rollback