Cross-site scripting defences: Crawl Audit check 164

Short answer: cross-site scripting (XSS) is when an attacker gets their own script to run on your page, usually through something a visitor typed or a link they clicked. The main fix is in your code; a strict Content-Security-Policy is the backup. Check 164 looks at whether your CSP would block inline scripts.

What Crawl Audit checks

• Pass: a CSP without 'unsafe-inline'.
• Warning: a CSP that includes 'unsafe-inline'.
• Warning: no CSP.

The catalogue calls this an input field reflection test, but Crawl Audit sends no test input and never tries an attack. It only reads your CSP header. It also warns on any 'unsafe-inline', even in a policy that uses nonces or hashes, where MDN notes browsers ignore it.

What the sources say

• OWASP: "Each variable used in the user interface should be passed through an output encoding function." That's the primary defence.
• OWASP supports CSP "when it is used properly", as a "defense-in-depth technique".
• MDN: "Developers should avoid 'unsafe-inline', because it defeats much of the purpose of having a CSP."
• MDN: "If a directive contains nonce or hash expressions, then the unsafe-inline keyword is ignored by browsers."

What to do

• Use your framework's built-in escaping, and don't bypass it to insert raw HTML from users.
• Move inline scripts into files, or mark them with nonces or hashes, then drop 'unsafe-inline' from script-src.
• Roll changes out in report-only mode first (check 149).

On devmarde.com

We don't send a CSP yet, so this check warns for us. Check 149 explains why and where it stands.

Sources

• OWASP, Cross Site Scripting Prevention Cheat Sheet.
• MDN, Content Security Policy (CSP) (updated 22 March 2026), checked 6 October 2026.