EngineeringScoreSecurity Medium
Add a Content-Security-Policy header
A Content-Security-Policy header is the browser-enforced allowlist for what a page is permitted to load and execute. It is the strongest single defense against cross-site scripting (XSS), because even if an attacker manages to inject a `<script>` tag, a well-configured CSP stops the browser from running it.
Why it matters
Without a Content-Security-Policy, the browser will run any script that ends up on the page, including ones an attacker injects, which is the primary way customer data gets stolen and sessions get hijacked.
How to fix
- 1 Inventory the scripts, styles, and resources the site actually loads.
- 2 Define a CSP header (script-src, style-src, connect-src, etc.) allowing only trusted origins.
- 3 Deploy first in Content-Security-Policy-Report-Only mode to catch breakage.
- 4 Switch to enforcing mode once the policy is clean.
Common mistakes
- Shipping straight to enforcing mode without a Report-Only rollout first, which breaks legitimate third-party scripts (analytics, chat widgets) in production.
- Using overly permissive directives like `script-src *` or `unsafe-inline` to avoid fixing inline scripts, which defeats most of the protection CSP is meant to provide.
- Writing the policy once and never revisiting it, so it silently blocks (or worse, silently allows) new third-party scripts added later by marketing or product teams.
How to verify
- 1 Inspect the response headers for Content-Security-Policy and confirm it lists specific origins rather than wildcards or unsafe-inline.
- 2 Open the browser console while browsing the site and confirm there are no CSP violation errors for legitimate functionality.
- 3 Deliberately try to inject a test inline script (e.g. via a form field) and confirm the browser blocks it and logs a violation.
Related checks
Ready to see where you stand?
Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.