Content Security Policy

Overview

Use this skill to inspect a project for CSP exposure, design a stronger policy, and apply it safely.

Run /csp audit when you need discovery and recommendations. Run /csp implement when you want the policy wired into the app.

Prefer a report-only rollout first unless the user explicitly asks to enforce immediately.

Workflow

1. Detect the stack and rendering model.
2. Audit every CSP-relevant surface.
3. Classify each item as refactor, nonce, hash, allowlist, or remove.
4. Draft the tightest practical policy.
5. Implement the policy and verify that the app still renders.
6. Re-run the audit after each CSP change to catch regressions.

Core Rules

• Eliminate unsafe-inline from script-src whenever a practical alternative exists.
• Keep object-src 'none' unless the app genuinely needs plugins.
• Add base-uri 'self' and a frame-ancestors policy.
• Prefer nonces for per-request inline code, hashes for static inline code, and refactoring for event handlers.
• Treat unsafe-eval as a last resort, usually only for development or legacy tooling.
• Start with Content-Security-Policy-Report-Only when the impact is uncertain.
• Prefer report-only plus browser-console verification before enforcing production changes.
• Treat any exception as temporary until it is justified by a real runtime need.

What To Inspect

• Server entry points and header middleware
• HTML templates and component render paths
• Inline <script> and <style> blocks
• Inline event handlers such as onclick
• eval, new Function, template compilation, and string-based script injection
• Script, style, image, font, connect, frame, worker, and media origins
• Third-party widgets, analytics, and payment providers
• Deployment layer headers that may need to be updated alongside app code

How To Work

1. Read mdn-csp-guide.md first for the canonical CSP model and browser behavior.
2. Read content-security-policy-complete.md for the extended CSP knowledge base.
3. Read github-skill-summary.md to borrow security-workflow patterns.
4. Read github-security-patterns.md for the actionable audit habits.
5. Read detect-stack.md to identify the stack quickly.
6. Read audit-checklist.md to catalog resources.
7. Read common-principles.md for policy design rules.
8. Read the matching stack reference before editing headers or nonce plumbing.
9. Use implement-flow.md to make the change and test it.

Rationalizations To Reject

• "We can leave unsafe-inline for now."
• "The inline script is tiny, so it is harmless."
• "We only need the allowlist in production."
• "The browser console warning is just noise."
• "We can add a wide domain wildcard and tighten it later."
• "The site works in report-only, so we do not need to remove the inline code."

Output Shape

When finishing an audit, provide:

• the detected stack
• a resource catalog
• inline-code findings
• recommended fixes
• the final CSP header

When implementing, provide:

• files changed
• how nonce or hash propagation works
• any residual exceptions or report-only items

Stack References

• MDN CSP Guide Notes
• CSP Knowledge Base
• GitHub Skill Summary
• GitHub Security Patterns
• Next.js
• Nuxt
• SvelteKit
• Remix
• Astro
• Express
• Fastify
• NestJS
• Hono
• Django
• Rails
• Laravel
• Spring Boot
• Nginx
• Apache
• Vercel
• Netlify
• Cloudflare
• Static HTML