CSP Evaluator

What is CSP?

CSP, or Content Security Policy, is a policy that tells a browser which resources a page may load and which forms of script execution it permits. Usually delivered in an HTTP header, it helps limit exploitation of XSS vulnerabilities without fixing the injection itself.

What a CSP blocks, and what it lets through

A Content Security Policy (W3C Content Security Policy Level 3) is a set of rules the server sends with the page. The browser then refuses to load or run anything they do not allow. Against cross-site scripting, a sound policy blocks injected inline scripts, event handlers such as onerror, javascript: URLs, eval() and scripts loaded from a domain that is not allowed.

It does not remove the injection itself. HTML injection remains possible: markup left open (dangling markup) can exfiltrate page content to an allowed image source, a fake form can post to an external domain if form-action is missing, and an allowed script that reads the DOM can run what the attacker puts there (DOM XSS, library gadgets). The header does not protect against CSRF either, and only covers clickjacking through frame-ancestors. A CSP is defence in depth: the vulnerability to fix is still the injection.

Classic bypasses

In 2016, Lukas Weichselbaum, Michele Spagnuolo, Sebastian Lekies and Artur Janc (Google) analysed the policies deployed on the web in “CSP Is Dead, Long Live CSP!” (ACM CCS 2016). They found bypasses in 94.72% of distinct policies, and 14 of the 15 domains most often allowed for scripts hosted exploitable endpoints. CSP Evaluator came out of that work.

'unsafe-inline', wildcards and bare schemes

'unsafe-inline' in script-src cancels most of the protection: <img src=x onerror=alert(1)> runs. A * wildcard, or a bare scheme such as https:, allows a file hosted on the attacker’s server. data: allows a script encoded in the URL: <script src="data:text/javascript,alert(1)">.

JSONP on an allowed domain

A JSONP endpoint returns JavaScript whose function name comes from a parameter, often callback. If the domain is allowed, <script src="https://allowed-domain/endpoint?callback=alert(1)//"> runs code chosen by the attacker, with the policy’s blessing. Large domains (Google, Yandex, Alibaba…) host many of them; the library keeps a list and the tool shows the endpoint it matched.

AngularJS and library gadgets

An allowed CDN that serves AngularJS lets the attacker load the library, then inject an ng-app template: AngularJS evaluates the expressions between braces with its own interpreter, with no inline script. The exact expression depends on the version (the expression sandbox was removed in 1.6); the PortSwigger XSS cheat sheet lists the variants. The same idea applies to script gadgets in other libraries (Lekies et al., “Code-Reuse Attacks for the Web”, ACM CCS 2017): legitimate code turns harmless HTML into execution.

base-uri, object-src and 'self'

Without base-uri, a <base href="https://attacker.example/"> tag injected before a relative script redirects its loading, including a script that carries a valid nonce. Without object-src 'none' or default-src, <object> and <embed> load active content; Flash left browsers in 2021, but the directive is still the rule. Finally, 'self' is bypassed as soon as the origin serves a file the attacker controls: an upload served with a JavaScript type, an internal JSONP endpoint or a copy of AngularJS.

Strict CSP: nonce or hash, and 'strict-dynamic'

The conclusion of the 2016 paper is to stop basing trust on domains. A strict CSP allows scripts by a nonce, a random value regenerated for every response and repeated in the nonce attribute of legitimate tags, or by the hash of their content for a static page. 'strict-dynamic' extends trust to the scripts those scripts create themselves, which keeps library loaders working, and makes CSP3 ignore hosts, schemes and 'self'. https: and 'unsafe-inline' stay as fallbacks for older browsers, which ignore them once they understand the nonce.

The form recommended by web.dev is the one offered in section 03: script-src 'nonce-…' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'none'. Its limits are known: a static or cached nonce protects nothing, an injection placed before a nonced script can try to hijack it, and DOM XSS goes through trusted scripts. require-trusted-types-for 'script' handles that last case by requiring a Trusted Types policy for sinks such as innerHTML.

Report-Only, meta tags and multiple policies

The Content-Security-Policy-Report-Only header blocks nothing: it only sends violations to report-uri or report-to. It is the right deployment step, and false protection if the policy stays there. The tool flags it and computes its verdict “as if enforced”.

A <meta http-equiv="Content-Security-Policy"> tag only applies to the content that follows it, and cannot carry frame-ancestors, report-uri or sandbox, which browsers ignore; Report-Only does not exist in a meta tag. When several policies are enforced (several headers, a comma-separated value, a header and a meta tag), the browser applies all of them: adding one can only restrict further.

Testing a CSP during an engagement

Collect the real headers page by page (curl -si https://target/ | sed '/^\r$/q'): the policy often differs between the application, error pages, the API and legacy routes, and a meta tag may add to it. Paste the raw response here; the tool keeps only the CSPs. Then check the mode (Report-Only or enforced) and whether the nonce changes when you reload.

For every allowed host, look for a JSONP endpoint (callback, jsonp, cb parameters), a copy of AngularJS or an upload service, on that domain as well as on 'self'. Confirm in a real browser, console open, that the payload runs without a violation. In the report, describe the full chain: the injection, then the policy bypass that makes it exploitable.