http.content_security_policy Reviewed July 2026

Quick fix

Inventory scripts, styles, frames, fonts, images, and connection destinations used by the application.

What this finding means

SecuTest checks for a `Content-Security-Policy` header and warns when it contains `unsafe-inline` or `unsafe-eval`. The scanner does not prove that the policy covers every route or that the application contains an injection vulnerability.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Cross-site scripting and malicious content injection

How the attack or failure scenario works

Cross-site scripting occurs when attacker-controlled content is executed as trusted script in a victim's browser. A restrictive CSP limits which scripts, styles, frames, and network destinations the browser may use, reducing the impact of many injection flaws. CSP is defense in depth and does not replace output encoding or safe APIs.

Conditions and limitations

  • The application has an injection path or a compromised third-party resource.
  • The victim loads the affected page.
  • The CSP is absent or permits the attacker's execution or exfiltration path.

Why it matters

Security and business impact A missing or permissive CSP does not create XSS by itself, but it removes a major defense that can limit script injection and data exfiltration.

Step-by-step fix

Where to make the change

  • The outermost component emitting the public HTTP response: CDN, reverse proxy, ingress, web server, or application middleware.
  • Apply the control consistently to normal pages, redirects, error responses, and relevant subdomains.

Remediation procedure

  1. Inventory scripts, styles, frames, fonts, images, and connection destinations used by the application.
  2. Deploy a report-only policy and collect violations without blocking production.
  3. Replace inline scripts with external files or nonce/hash-based authorization and remove `unsafe-eval`.
  4. Promote the tested policy to enforcement and keep route-specific exceptions narrow.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Nginx baseline
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; script-src 'self'; style-src 'self'" always;

Apache baseline
Header always set Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; script-src 'self'; style-src 'self'"

Report-only rollout
Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint

Verify the fix

  1. Run `curl -sS -D- -o /dev/null https://example.com/` and inspect the CSP header.
  2. Use browser developer tools and CSP violation reports to identify blocked legitimate resources.
  3. Test authenticated, error, checkout, and embedded-content routes.
  4. Confirm `script-src` does not rely on broad wildcards or unnecessary unsafe keywords.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Copying a strict sample directly into production without inventorying application dependencies.
  • Keeping `unsafe-inline` permanently instead of using nonces or hashes.
  • Assuming CSP makes unsafe template rendering or DOM APIs acceptable.

Authoritative references