Frontend Security: XSS, CSRF, CSP, and Modern Defenses

By /
⏱ 3 min read

Frontend security is increasingly tested in senior interviews — not because every engineer should be a security specialist but because the consequences of getting basic patterns wrong are catastrophic. XSS, CSRF, and SSRF are the OWASP top three; understanding the defenses is professional baseline.

Cross-Site Scripting (XSS)

The attacker injects script that runs in the victim’s browser. Three types:

  • Stored XSS: attacker script saved on server (e.g., in a comment), runs for every viewer
  • Reflected XSS: attacker tricks user into clicking a URL that includes script
  • DOM-based XSS: attacker exploits client-side JS that uses untrusted data unsafely

Defenses

  • Always escape output. React, Vue, and modern frameworks do this by default — bypass only with explicit raw-HTML props
  • Sanitize HTML input with DOMPurify if you must accept HTML
  • Set Content Security Policy headers
  • Use Trusted Types API (Chromium-only as of 2026) to enforce safe sinks at runtime

Content Security Policy (CSP)

HTTP header that whitelists allowed sources for scripts, styles, images, etc.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'

A strict CSP is the single most effective XSS mitigation. Even if attacker injects script, CSP blocks execution.

Common gotcha: unsafe-inline defeats most of the protection. Use nonces or hashes instead.

Cross-Site Request Forgery (CSRF)

Attacker tricks the user’s browser into making a request to your site that the user did not intend. Browser sends cookies; the request looks authenticated.

Defenses

  • SameSite cookies: set SameSite=Lax or Strict on auth cookies. Browser refuses to send them on cross-site requests.
  • CSRF tokens: server generates a token, embeds in the form, validates on submit. Attacker cannot read the token from another origin.
  • Custom request headers: require an X-Custom-Header on state-changing requests; CORS prevents arbitrary origins from setting it.

Modern web apps using SPA + JSON APIs typically rely on SameSite + token in header (not in cookie).

SameSite cookies

Three values:

  • Strict: cookie sent only on same-site requests. Most secure; can disrupt legitimate flows like reflecting back from a payment processor.
  • Lax (default in 2026): cookie sent on same-site + top-level GET navigations from other sites. Reasonable balance.
  • None: cookie sent on all requests. Requires Secure flag. Use only when needed for cross-site embedded use cases.

Subresource Integrity (SRI)

For third-party scripts loaded from CDN, include a hash:

<script src="https://cdn.example.com/lib.js" integrity="sha384-abc..." crossorigin="anonymous">

Browser refuses to execute the script if the hash does not match. Defeats CDN tampering.

Clickjacking

Attacker iframes your site, overlays invisible UI, tricks user into clicking on hidden buttons.

Defenses:

  • X-Frame-Options: DENY or SAMEORIGIN header
  • Content-Security-Policy: frame-ancestors 'self'

HTTPS and HSTS

HTTPS everywhere is table stakes. Add HSTS (HTTP Strict Transport Security) header to force browsers to use HTTPS even for typed-in URLs.

Submit your site to HSTS preload list for browser-baked enforcement.

Secrets in the frontend

Never put secrets in frontend code:

  • API keys with privileged access
  • Database credentials
  • Internal admin URLs

Anything in JS source is public. Use a backend proxy for privileged operations.

Third-party scripts

Every third-party script (analytics, ads, fonts) is a potential XSS source. Mitigations:

  • SRI hashes for static URLs
  • Sandboxed iframes for ad networks
  • CSP whitelist of allowed origins
  • Audit periodically

Common interview probes

  • “How does XSS happen and how do you prevent it?”
  • “Walk through CSRF and three defenses”
  • “What is CSP and what is unsafe-inline?”
  • “How do SameSite cookies prevent CSRF?”

Frequently Asked Questions

Does using React eliminate XSS risk?

Mostly. React escapes by default. The risk lives in raw-HTML props, innerHTML, and unsafe URL handling (e.g., href={userInput} without protocol check).

Should I use httpOnly cookies for auth?

Yes for tokens stored in cookies — prevents JS access (mitigates XSS-based theft). Use Secure and SameSite as well.

Are JWTs in localStorage safer or less safe?

Less safe than httpOnly cookies. localStorage is JS-readable, so an XSS allows token theft. Cookies with httpOnly cannot be stolen from JS.

Scroll to Top