Unsafe Content Security Policy
ID |
html.unsafe_content_security_policy |
Severity |
low |
Remediation Complexity |
medium |
Remediation Risk |
medium |
Remediation Effort |
low |
Resource |
Access Control |
Language |
Html |
Tags |
ASVS50:v3.4.6, CWE:693, NIST.SP.800-53, OWASP:2025:A06, PCI-DSS:6.5.4, PCI-DSS:6.5.6 |
Description
This rule identifies HTML documents that either do not define a Content Security Policy (CSP) via a meta tag or define a weak CSP that permits unsafe script execution. In particular, it flags policies that allow inline script execution, dynamic code evaluation, or overly permissive source definitions.
A missing policy is reported only for pages the application serves, and only when the application sets no policy elsewhere. A policy that covers every response counts: one set by middleware (helmet, django-csp, Flask-Talisman, Spring Security, ASP.NET Core, or a header set inside the application’s own middleware or filter) or by the web server configuration (nginx add_header, Apache Header set). A header set on a single response in a view or handler, such as a sandboxed file download, does not: it leaves the pages without a policy. Pages that are not served as application pages are not reported for a missing policy: email templates, test, demo and documentation pages, and the development page of a package that publishes a library.
Because CSP is commonly delivered via HTTP headers, this rule operates at the HTML level and focuses on detectable CSP misconfigurations within markup.
Rationale
Content Security Policy (CSP) is a defense-in-depth control designed to reduce the impact and exploitability of Cross-Site Scripting (XSS) vulnerabilities. An unsafe or missing CSP significantly weakens the browser’s ability to prevent injected script execution.
Common risks associated with weak CSP configurations include:
CSP Bypass: Directives such as unsafe-inline, unsafe-eval, or wildcard (*) sources undermine the protections offered by CSP and allow injected JavaScript to execute.
Expanded Attack Surface: Without strict script source restrictions, an attacker who achieves HTML or JavaScript injection can execute arbitrary code.
Missed Hardening Opportunity: Even in the absence of known XSS vulnerabilities, a strict CSP limits the blast radius of future or undiscovered issues.
Consider the following insecure examples:
<meta http-equiv="Content-Security-Policy"
content="default-src *; script-src 'unsafe-inline' 'unsafe-eval'"><meta http-equiv="Content-Security-Policy"
content="script-src *">Remediation
Implement a strict Content Security Policy and avoid unsafe script execution directives.
Where possible, enforce CSP using HTTP response headers rather than HTML meta tags. If a meta tag is required, ensure it defines a restrictive policy.
Recommended baseline policy:
Corrected Example:
<meta http-equiv="Content-Security-Policy"
content="default-src 'self'; script-src 'self'; object-src 'none'">