XSS Cross-Site Scripting – Java Backend Security
Fast recall
Quick revision
Core answer
unsafe-inline, unsafe dependencies, or script gadgets.Interview-ready guide
Interview answer
Content Security Policy is a response header that tells the browser which resources and execution paths a page may use. It can limit scripts, styles, images, connections, frames, form targets, and other content.
For XSS mitigation, a strong script policy commonly uses a fresh nonce on each response or hashes for fixed scripts. The browser runs only script elements that carry an approved nonce or match a hash, so injected inline script without that value is blocked. A policy that only says script-src 'self' is weaker because every script served from the same origin remains trusted.
CSP does not sanitize attacker data or fix unsafe innerHTML. It is defense in depth alongside safe templates, context-aware output handling, secure dependencies, and safe DOM APIs. I would first send Content-Security-Policy-Report-Only, inspect real violations, remove broad allowances such as unsafe-inline, then enforce and monitor the final policy.
XSS Cross-Site Scripting – Java Backend Security
Direct Answer
Content Security Policy is a browser-enforced response policy that limits where scripts, styles, frames, and other resources may come from and how they may execute. A strict script policy based on nonces or hashes can block many injected inline scripts even when markup injection exists. CSP is defense in depth: it does not sanitize data, does not repair unsafe DOM code, and can be weakened by broad sources, unsafe-inline, unsafe dependencies, or script gadgets.
Code Example
String nonce = nonceService.newNonce();
response.setHeader("Content-Security-Policy",
"default-src 'none'; script-src 'nonce-" + nonce + "'; " +
"style-src 'self'; img-src 'self'; connect-src 'self'; " +
"base-uri 'none'; object-src 'none'; frame-ancestors 'none'");
model.addAttribute("cspNonce", nonce);
<script th:attr="nonce=${cspNonce}" src="/assets/app.js"></script>
Generate a new unpredictable nonce for each response and place it only on trusted script elements. Start with the equivalent Report-Only header when introducing the policy.
Common Mistakes & Pitfalls
- Treating CSP as the whole fix: it's a second layer; output encoding is primary.
- Adding
'unsafe-inline': this re-allows inline scripts and largely defeats CSP's XSS value. - Forgetting it's browser-enforced: old browsers may ignore it, so don't depend on CSP alone.
- Over-broad policies:
script-src *allows everything — be specific ('self', named CDNs). - Enforcing blind: roll out with report-only first to catch legitimate scripts you'd otherwise break.
Check your understanding
Answer these without looking back at the article.
- Why does 'unsafe-inline' defeat much of CSP's XSS protection?
- How do nonces or hashes let you allow specific inline scripts safely?
- Is CSP a replacement for output encoding, or a complement to it?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.