How Do CSP Nonces Prevent Inline Script Injection?
Understand how CSP nonces work, why they beat unsafe-inline, and how to implement per-request nonces to stop XSS.
Expected Interview Answer
A CSP nonce is a random, single-use token the server generates per response and embeds both in the Content-Security-Policy header and as a nonce attribute on each legitimate inline script tag, so the browser executes only scripts carrying the matching token and blocks any injected script that lacks it.
Without a nonce, a strict Content-Security-Policy either has to allow all inline scripts (defeating XSS protection) or ban them entirely (breaking apps that rely on inline bootstrapping code). A nonce solves this by letting the server whitelist specific inline scripts on a per-response basis: it generates a fresh cryptographically random value for every request, sends script-src 'nonce-<value>' in the CSP header, and adds nonce="<value>" to each trusted inline <script> tag. The browser only executes an inline script if its nonce attribute matches the one declared in the header for that exact response. Because the nonce must be unpredictable and regenerated per request, an attacker who injects a script via an XSS vulnerability cannot guess the current nonce, so their injected script gets blocked even though legitimate inline scripts run normally. This makes nonces strictly better than a static 'unsafe-inline' allowance, and they are considered a modern best practice alongside or instead of hash-based CSP allowances.
- Allows specific trusted inline scripts to run while blocking injected ones
- Removes the need for a blanket, XSS-defeating unsafe-inline allowance
- Nonce unpredictability means attacker-injected scripts cannot forge a match
- Regenerated per request, so a leaked nonce from one response is useless on the next
AI Mentor Explanation
A CSP nonce is like a match-day wristband with a code printed fresh for that specific game, handed only to accredited players before they walk onto the field. Security staff check the wristband code against today’s printed list before letting anyone through the boundary rope; yesterday’s wristband or a guessed code doesn’t match and gets refused. A gate-crasher who sneaks past the outer fence still can’t get past the wristband check because they never received today’s code. That per-event, unpredictable, checked-at-the-gate token is exactly how a nonce lets legitimate inline scripts run while blocking injected ones.
Step-by-Step Explanation
Step 1
Server generates a random nonce per request
A cryptographically random value is created fresh for every response, never reused across requests.
Step 2
Nonce is embedded in the CSP header
The server sends Content-Security-Policy: script-src 'nonce-<value>' along with the response.
Step 3
Matching nonce is attached to trusted inline scripts
Each legitimate inline <script> tag gets nonce="<value>" matching the header for that response.
Step 4
Browser executes only matching scripts
During rendering, the browser compares each inline script’s nonce attribute to the header value and blocks any that don’t match, including injected scripts.
What Interviewer Expects
- Explaining that the nonce must be random and regenerated per response
- Understanding why nonces are strictly better than a blanket unsafe-inline allowance
- Awareness that an XSS-injected script cannot guess the current nonce
- Mentioning hash-based CSP as an alternative for static inline scripts
Common Mistakes
- Reusing the same nonce across multiple requests or hardcoding it
- Generating the nonce client-side instead of server-side per response
- Forgetting that unsafe-inline is ignored by browsers once a nonce or hash is present
- Confusing a nonce with a CSRF token, which serves a different purpose
Best Answer (HR Friendly)
“A CSP nonce is a random one-time code the server creates for each page load and stamps on both the security policy and the scripts it trusts. The browser only runs scripts carrying that exact code, so if an attacker manages to inject their own script, it won’t have the right code and simply won’t run.”
Code Example
const crypto = require('crypto')
app.use((req, res, next) => {
res.locals.nonce = crypto.randomBytes(16).toString('base64')
res.set(
'Content-Security-Policy',
`script-src 'self' 'nonce-${res.locals.nonce}'; object-src 'none'`
)
next()
})
app.get('/', (req, res) => {
res.send(`
<html>
<script nonce="${res.locals.nonce}">
console.log('trusted inline script')
</script>
</html>
`)
})Follow-up Questions
- Why is a static, hardcoded nonce value effectively useless?
- How do CSP hashes differ from nonces for allowing inline scripts?
- How would you apply a nonce to scripts injected by a third-party analytics tag?
- What CSP directive would you pair with nonces to also restrict script sources by origin?
MCQ Practice
1. What property must a CSP nonce have to be effective?
A predictable or reused nonce can be guessed or replayed by an attacker, defeating its purpose.
2. Why does a CSP nonce block an XSS-injected inline script?
Since the nonce is unpredictable and regenerated per response, an attacker’s injected script has no way to include the correct matching nonce attribute.
3. What happens to a script-src 'unsafe-inline' directive once a nonce is also present in the CSP header?
Modern browsers ignore unsafe-inline when a nonce or hash source is present, so relying on nonces provides real protection.
Flash Cards
What is a CSP nonce? — A random, per-response token embedded in the CSP header and on trusted inline scripts so the browser only executes matching scripts.
Where must the nonce be generated? — Server-side, freshly, for every single response — never reused or client-generated.
Why do nonces beat unsafe-inline? — unsafe-inline permits every inline script including injected ones; a nonce whitelists only scripts with the matching unpredictable value.
What alternative exists for static inline scripts? — Hash-based CSP sources, which allow a specific script by the hash of its exact content.