Q258: Content Security Policy Rollout and XSS Defense Depth

What Interviewers Want To Evaluate

Interviewers want to know whether you can explain CSP as practical defense-in-depth, not as a magic switch.

They want rollout judgment: report-only mode, nonce or hash strategy, third-party governance, monitoring, compatibility, and how CSP fits with XSS prevention.

Short Interview Answer

Content Security Policy is an HTTP response policy that restricts which scripts, styles, images, frames, connections, and other resources a browser may load or execute. It helps reduce XSS blast radius, especially when paired with nonces or hashes and without unsafe inline script. I would roll it out in Content-Security-Policy-Report-Only first, collect violations, inventory third parties, tighten directives gradually, monitor reports, and keep fixing root XSS issues rather than treating CSP as the only defense.

Detailed Interview Answer

CSP is one of the most useful browser security headers.

It lets the server tell the browser:

only execute scripts from these trusted places
only connect to these APIs
only embed frames from these origins
only submit forms to these destinations

That is powerful because XSS often depends on injecting or executing script.

But CSP must be designed carefully.

A weak CSP can create confidence without real protection.

Common Directives

Important directives include:

default-src
script-src
style-src
img-src
connect-src
font-src
frame-src
frame-ancestors
object-src
base-uri
form-action
report-uri
report-to
upgrade-insecure-requests

default-src is the fallback.

Specific directives override it.

Script Policy

Script execution is usually the highest-risk area.

Stronger script policies avoid:

'unsafe-inline'
'unsafe-eval'
wildcard script sources
overly broad third-party hosts

Better patterns include:

nonces
hashes
strict-dynamic where appropriate
self-hosted known scripts
third-party script governance

Nonce-based CSP works well when the server can generate a fresh nonce per response and apply it to approved script tags.

Report-Only Rollout

Start with:

Content-Security-Policy-Report-Only

This allows you to observe violations without breaking users.

Collect reports and answer:

which scripts currently run?
which vendors are needed?
which inline scripts exist?
which eval paths exist?
which routes differ?
which browser extensions create noise?

Then move toward enforcement once the policy is understood.

Third-Party Governance

Every third-party script is a trust decision.

Ask:

what data can it read?
can it read form inputs?
can it send network requests?
is it needed on this route?
is there an iframe alternative?
does it hurt performance?
who owns updates?

CSP can limit destinations, but if a vendor script is allowed to execute in your origin, it still has broad power.

CSP and Frameworks

Modern frameworks may need special handling.

Consider:

hydration scripts
inline bootstrap data
dynamic imports
style injection
development-only eval
analytics scripts
RSC payloads

Development CSP and production CSP may differ.

Never weaken production policy just because development tooling needs eval.

CSP Does Not Replace Escaping

CSP is defense-in-depth.

You still need:

output escaping
safe HTML rendering
avoiding dangerous innerHTML
sanitization for user content
dependency review
server validation
least privilege

If untrusted content is rendered as executable HTML, CSP may reduce damage, but the root bug remains.

Debugging Violations

When CSP blocks something, inspect:

violated directive
blocked URI
document URI
source file
line number
sample if available
route
release version
browser

Do not blindly add the blocked origin.

First decide whether the blocked behavior is expected and safe.

Useful Baseline Ideas

A stronger baseline often includes:

object-src 'none'
base-uri 'self'
frame-ancestors 'none' or explicit allowlist
form-action 'self'
script-src with nonce or hashes
connect-src limited to known APIs

Exact policy depends on product needs.

Interviewers care more about reasoning than memorizing one policy string.

Common Mistakes

Common mistakes include:

shipping a broad wildcard policy
allowing unsafe-inline permanently
adding vendors without review
not monitoring reports
breaking production routes with immediate enforcement
ignoring route-specific needs
forgetting CSP is per response
thinking CSP fixes XSS by itself

Interview Example

If asked, "How would you add CSP to a large app?"

Answer:

"I would inventory resource usage, start with report-only, collect violations by route and release, remove unnecessary inline and eval usage, choose nonce or hash strategy for scripts, govern third-party sources, enforce low-risk directives first, then gradually enforce stricter script and connect policies with monitoring and rollback."

Senior-Level Framing

The senior framing:

"CSP is a browser-enforced contract for resource execution. I use it to reduce XSS blast radius and govern third-party code, but I still fix injection bugs at the source."

Practice Prompt

Design a CSP rollout for:

public handbook pages
practice console pages
analytics
PDF downloads
embedded code examples
third-party deployment scripts

List the directives you would start with and which ones need report-only validation.

Final Mental Model

CSP is a seatbelt, not a driving lesson.

It can save you when something goes wrong, but the system still needs safe rendering, careful dependencies, and explicit trust boundaries.