Security headers · Check
Weak CSP — removing unsafe-inline, wildcards, and other escape hatches
Permissive CSP keywords (`unsafe-inline`, `unsafe-eval`, wildcard sources) keep CSP enabled in name only. Attackers who plant inline script can still execute, and supply-chain compromises stay easy to weaponize.
Real-world risk
Permissive keywords (e.g. unsafe-inline, wildcards) weaken CSP so attackers can still run script.
Fix steps (in order)
- Remove unsafe-inline / unsafe-eval for script-src; use nonces or hashes for required inline script.
- Replace * sources with explicit host allowlists.
Example configurations
Patterns for common stacks. Set headers at your CDN, load balancer, or origin as appropriate.
nginx (tighten script-src) · nginx
# Drop 'unsafe-inline' / wildcards in production; use nonces or hashes for any inline script. add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'" always;
Express (helmet) · typescript
import helmet from "helmet"; app.use( helmet.contentSecurityPolicy({ directives: { defaultSrc: ["'self'"], scriptSrc: ["'self'"], objectSrc: ["'none'"], }, }), );Apache · apache
# Replace permissive policy with explicit hosts and no unsafe-inline where possible. Header set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'"
Topic explainer
What is Content Security Policy (CSP)? A practical explainer →
An accessible explanation of Content Security Policy: what it does, why it exists, the directives that matter, and how to roll one out without breaking your app.
Verify the fix in 30 seconds
Run a Scorifya scan on the affected host after deploy. The same finding id (weak_csp) clears once the externally-observable signal is in place.