CSP XSS
CSPs weaken cross-site scripting (XSS) attacks by stopping malicious scripts being inserted by attackers.
Security
No CSP found in enforcement mode
Why should you include a CSP (Content Security Policy) in your web pages? Because by doing so, you can be sure that any content loaded on the page is trusted.
CSPs weaken cross-site scripting (XSS) attacks by stopping malicious scripts being inserted by attackers. The CSP, however, can be circumvented without too much trouble if it is not strictly written.
If no CSP is found in enforcement mode, SeoChecker will notify you:
If you want to be sure that your CSP can not be bypassed, follow these practices:
A CSP must have no syntax errors and must include the script-src, object-src and base-uri directives to target XSS.
script-src is intended to protect the page from unsafe scripts, while object-src protects it from unsafe plugins. If you want to configure a more generic and less specific setting, you can use default-src.
base-uri instead prevents the injection of unauthorised <base> tags: these can be used by attackers to redirect all related URLs (such as scripts) to their domains.
- To avoid allowlist bypasses, CSP uses nonces or hashes
When a CSP configures a script-src allowlist it means that it assumes that all responses coming from a trusted domain are secure and can therefore be executed as scripts. This assumption, however, is not so obvious for modern applications: there are usually common and benign patterns that can be used by attackers to bypass the CSP.
Thus, an attacker can bypass most script-src allowlists with an XSS bug; moreover, allowlists do not grant real protection against script injection. One solution is nonce-based and hash-based approaches.
Take a look at this code that uses a JSONP endpoint hosted on a trusted domain to inject a script controlled by an attacker:
CSP:
script-src https://trusted.example.com
HTML
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
Therefore, let the CSP use “strict-dynamic” and allow scripts one by one through nonces or hashes.
There are other recommendations besides the previously mentioned:
- Monitor the breakages configuring a reporting destination. Use the report-uri or report-to directives.
- If it's possible for you, define a CSP in an HTTP response header:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
- Considering that nonces and hashes, as well as strict-dynamic, are not supported by all browsers, you should add unsafe-inline and an allowlist as a fallback.
Examples of strict CSP
Strict CSP with a nonce-based policy:
CSP:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>