Q236: Content Security Policy and Security Headers

What Interviewers Want To Evaluate

Interviewers want to know whether you understand browser security controls that protect frontend applications after code is shipped.

They check Content Security Policy, script sources, nonce and hash strategies, frame protection, referrer policy, permissions policy, HSTS, reporting, third-party scripts, and how security headers interact with performance and delivery.

Short Interview Answer

Content Security Policy limits which scripts, styles, images, frames, and connections a page can use, reducing the blast radius of XSS and injection bugs. I would start with report-only mode, inventory real sources, remove unsafe script patterns, use nonces or hashes for trusted inline scripts, govern third-party scripts, and add reporting. Security headers like HSTS, Referrer-Policy, Permissions-Policy, and frame protections complement CSP by reducing browser attack surface.

Detailed Interview Answer

Frontend security is not only escaping strings.

The browser can enforce useful guardrails.

Security headers help control:

where scripts can load from
which origins can be framed
how much referrer data is sent
which browser capabilities are allowed
whether HTTPS is required
where violations are reported

These controls matter for content-heavy and script-heavy applications.

CSP Mental Model

Content Security Policy is a allowlist policy.

Example:

Content-Security-Policy:
  default-src 'self';
  script-src 'self';
  img-src 'self' https: data:;
  connect-src 'self' https://api.example.com;

This tells the browser what sources are allowed.

If unexpected script is injected, the browser can block it.

script-src

script-src is one of the most important directives.

Risky:

script-src 'self' 'unsafe-inline' *

Better:

script-src 'self' 'nonce-randomValue' https://trusted-vendor.example

Avoid broad wildcard script sources.

Every third-party script should be justified.

Nonces And Hashes

Inline scripts can be allowed with nonces or hashes.

Nonce approach:

<script nonce="abc123">
  bootstrapApp();
</script>

The server sends a matching CSP nonce.

Hashes work for static inline content.

Nonces are often better for dynamic server-rendered pages.

Report-Only Rollout

Do not deploy a strict CSP blindly.

Start with:

Content-Security-Policy-Report-Only

Then:

collect violations
remove unexpected sources
fix inline script usage
coordinate vendors
move to enforcing policy
continue monitoring

This prevents breaking production by surprise.

Third-Party Scripts

CSP forces visibility into vendors.

Ask:

why is this script needed
who owns it
when does it load
does it need user consent
does it affect INP
does it require broad CSP permissions

Security and performance governance overlap here.

frame-ancestors

frame-ancestors controls who can embed your page.

Example:

frame-ancestors 'none'

or:

frame-ancestors 'self' https://trusted.example

This helps prevent clickjacking.

It is preferred over older X-Frame-Options for modern CSP-based control.

Referrer-Policy

Referrer policy controls how much URL information is sent to other origins.

Common safe default:

Referrer-Policy: strict-origin-when-cross-origin

Avoid leaking sensitive paths or query strings to third-party sites.

Permissions-Policy

Permissions policy controls browser capabilities.

Example:

Permissions-Policy: camera=(), microphone=(), geolocation=()

Disable features the app does not need.

This reduces attack surface and accidental permission prompts.

HSTS

HTTP Strict Transport Security tells browsers to use HTTPS.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Use carefully.

Once cached, browsers enforce it for the duration.

Make sure HTTPS is correctly configured first.

Common Mistakes

Common mistakes include:

allowing unsafe-inline permanently
using wildcard script sources
deploying strict CSP without report-only testing
forgetting WebSocket or API connect-src needs
breaking third-party scripts without ownership
not monitoring CSP reports
confusing CSP with complete XSS prevention

CSP is defense in depth, not a replacement for safe rendering.

Senior Trade-Offs

CSP can be strict and still practical.

Trade-offs:

strict security vs vendor flexibility
nonce strategy vs implementation complexity
blocking unsafe inline code vs migration effort
report volume vs signal quality

The senior approach is phased rollout with owners.

Interview Framing

In an interview, say:

I use CSP and security headers as browser-enforced guardrails. I roll CSP out in report-only mode, remove unsafe sources, use nonces or hashes for trusted inline scripts, govern vendors, and monitor violations.

Revision Notes

• CSP controls allowed sources for browser resources.
• script-src is critical for XSS blast-radius reduction.
• Nonces and hashes are safer than broad inline allowances.
• Report-only mode prevents accidental production breakage.
• Security headers complement application code safety.
• Third-party script governance is both security and performance work.

Follow-Up Questions

• What does CSP protect against?
• Why is unsafe-inline risky?
• How would you roll out CSP safely?
• What does frame-ancestors do?
• How can CSP affect third-party scripts?

How I Would Answer This In A Real Interview

I would say CSP is a browser-level safety boundary that limits which resources can execute or load. I would not flip on a strict policy blindly. I would start in report-only mode, inventory sources, remove unsafe inline patterns, use nonces or hashes, control third-party script sources, and monitor violations. I would pair CSP with HSTS, Referrer-Policy, Permissions-Policy, and frame protections.