Why CSP Strictness Audit Exists

The CSP Strictness Audit is the audit you reach for when you already suspect a problem in this dimension and need a fast, copy-paste-able fix list. It reuses the same chrome as every other jwatte.com tool — deep-links from the mega analyzers, AI-prompt export, CSV/PDF/HTML download — but the checks it runs are narrow and specific.

Deep Content-Security-Policy audit: nonce/hash coverage, strict-dynamic, unsafe-inline, report-to coverage, Trusted Types directive, wildcard source list quality.

What it actually checks

This is a partial extract of the audit's real findings — the same strings the tool prints when a check trips. Use it as a quick sanity check before you run the audit live:

Why this dimension matters

Modern browsers fail closed on missing or misconfigured security headers — a single wrong header (CSP with unsafe-inline, ACAO wildcard with Allow-Credentials: true, SRI hash mismatch) turns a production site into an XSS or data-exfiltration risk. Audit-side these are silent; users notice only after a breach or a PCI / SOC-2 review asks.

Common failure patterns

• Permissive CORS combined with credentials — Access-Control-Allow-Origin: * plus Access-Control-Allow-Credentials: true is ignored by browsers but signals sloppy review. The real failure is ACAO echo-back (reflecting any Origin header) paired with credentials; that exposes authenticated endpoints to cross-site scripts.
• CSP unsafe-inline / unsafe-eval — a CSP that allows inline or eval defeats most of its own purpose. Modern apps should emit nonces or hashes and remove inline handlers; the audit flags the pattern and points to the Trusted Types + Inline Event Handler tools as the next step.
• Security headers on HTML but not on APIs — the HTML response gets HSTS, CSP, and X-Frame-Options; the JSON API response doesn't. An attacker only needs one unhardened origin.

How to fix it at the source

Start from a deny-by-default CSP and relax per directive. For CORS, prefer an explicit allowlist over *. Apply headers at the CDN / edge layer (Netlify _headers, Vercel vercel.json, Cloudflare Transform Rules, nginx add_header) rather than in application code — the edge layer catches every response consistently.

When to run the audit

• After a major site change — redesign, CMS migration, DNS change, hosting platform swap.
• Quarterly as part of routine technical hygiene; the checks are cheap to run repeatedly.
• Before an investor / client review, a PCI scan, a SOC 2 audit, or an accessibility-compliance review.
• When a downstream metric drops (rankings, conversion, AI citations) and you need to rule out this dimension as the cause.

Reading the output

Every finding is severity-classified. The playbook is the same across tools:

• Critical / red: same-week fixes. These block the primary signal and cascade into downstream dimensions.
• Warning / amber: same-month fixes. Drag the score, usually don't block.
• Info / blue: context-only. Often what a PR reviewer would flag but that doesn't block merge.
• Pass / green: confirmation — keep the control in place.

Every audit also emits an "AI fix prompt" — paste into ChatGPT / Claude / Gemini for exact copy-paste code patches tied to your stack.

Related tools

• Mega Security Analyzer — Seven security layers in one scan: TLS, PQC hybrid-KEX, HTTP security headers, DNS email-auth (SPF/DKIM/DMARC/CAA), CSP strictness, MITRE ATT&CK tactic mapping, CWE / OWASP / SANS pattern scan.
• CORS Headers Audit — Deep CORS audit: ACAO * + credentials, Vary: Origin, Allow-Methods, Expose-Headers, Max-Age, Timing-Allow-Origin..
• Subresource Integrity (SRI) Audit — Checks SRI integrity hash coverage on every cross-origin