The browser is doing more security work than you realize. Here's what happens when you accidentally get in its way.

In this article we'll cover how XSS actually happens in real frontend codebases, how CSRF works and where the browser's default protections break down, how clickjacking works and how one header stops it, what Content Security Policy actually does and how to implement it without breaking your app, and the CORS misconfigurations that create vulnerabilities while feeling like security.

Frontend security has a reputation for being someone else's problem. The backend handles auth, the infrastructure team handles firewalls and the frontend just renders what it's given.

That mindset is expensive.

I've worked on platforms handling more than 10 million active users. At that scale, a single security misconfiguration isn't a bug report - it's an incident. And the uncomfortable truth is that most of the vulnerabilities I've seen on the frontend weren't sophisticated attacks. They were gaps left behind by developers who didn't know the browser was already protecting them and accidentally turned that protection off.

This article is about understanding what the browser does for you by default, so you never accidentally undo it.

XSS - The Attack That Lives in Your Own Code

Cross-Site Scripting is the most common frontend vulnerability. The idea is simple: an attacker finds a way to get malicious JavaScript to run in your page, in your users' browsers, with access to everything your page has access to - cookies, localStorage, DOM, API tokens.

The most important thing to understand about XSS is that it doesn't require a sophisticated attacker. It requires a place in your codebase where user-controlled content is rendered without sanitization.

// This is all it takes
document.getElementById('username').innerHTML = userInput

If userInput contains <script>alert(document.cookie)</script> that script runs. Game over.

Modern frameworks help significantly here. React, Vue, and Angular all escape output by default. When you write {userInput} in JSX, React treats it as text, not HTML. That's the browser's XSS protection working through the framework.

The danger is when you deliberately bypass it:

// This bypasses React's built-in escaping
<div dangerouslySetInnerHTML={{ __html: userContent }} />

dangerouslySetInnerHTML exists for legitimate reasons - rendering rich text, markdown output, CMS content. But every time you use it, you're taking on the responsibility of sanitizing that content yourself.

If you need to render HTML from an untrusted source, sanitize it first:

import DOMPurify from 'dompurify'

const clean = DOMPurify.sanitize(userContent)
// Now safe to render

DOMPurify strips anything that could execute JavaScript while preserving legitimate HTML structure. At scale, this belongs in a shared utility, not copied across components.

The other XSS surface most teams miss: third-party scripts.

Every analytics library, chat widget, and ad script you load is running JavaScript in your page with the same privileges as your own code. If any of those scripts are compromised - through a supply chain attack on the npm package or a hijacked CDN - your users are exposed.

This is where Content Security Policy becomes critical, which we'll cover shortly.

CSRF - The Attack the Browser Already Mostly Fixed

Cross-Site Request Forgery works like this: a user is logged into your platform. They visit a malicious site. That site silently makes a request to your platform's API - a request that carries the user's cookies automatically, because that's how cookies work.

If your API trusts cookie-authenticated requests without verifying their origin, the attacker can perform actions on behalf of the user without them knowing.

The browser has quietly been fixing this for years through the SameSite cookie attribute.

Set-Cookie: session=abc123; SameSite=Lax; Secure; HttpOnly

SameSite=Lax tells the browser: only send this cookie on requests that originate from the same site or on top-level navigation. Cross-site requests from a malicious page won't carry the cookie.

SameSite=Strict is even more restrictive - the cookie won't be sent on any cross-site request, including navigations. Good for sensitive session cookies.

Most modern browsers now default to SameSite=Lax even if you don't set it explicitly. That's the browser protecting you without you asking.

Where this breaks down:

If your frontend and API are on different domains - app.yourplatform.com and api.yourplatform.com - cookie handling gets more complex. Subdomains are generally considered same-site, but cross-domain setups are not.

If you're using token-based auth with the Authorization header instead of cookies, CSRF is largely not your problem. Browsers don't automatically attach Authorization headers to cross-site requests the way they do with cookies.

But if you're mixing both - cookies for session management and tokens for API calls - understand exactly what each request is sending and why.

Clickjacking - The Invisible Iframe Attack

Clickjacking is straightforward in concept. An attacker embeds your platform in an invisible iframe on their site, positioned perfectly over a button the attacker wants you to click. You think you're clicking something on the attacker's page. You're actually clicking something on yours.

On a platform with payment flows, subscription management or any destructive actions, this is a real risk.

One HTTP header stops it entirely:

X-Frame-Options: DENY

Or the more modern equivalent via Content Security Policy:

Content-Security-Policy: frame-ancestors 'none'

DENY means your page cannot be embedded in any iframe, on any site. If you need to allow embedding on specific trusted domains:

Content-Security-Policy: frame-ancestors 'self' https://trusted-partner.com

This is one of those protections that takes 30 seconds to implement and eliminates an entire category of attack. There is almost no reason not to have it.

Content Security Policy - The Most Powerful Tool Nobody Uses

CSP is the most underutilized browser security feature in frontend development. It's also the most powerful.

A Content Security Policy is a HTTP header that tells the browser exactly what it's allowed to load and execute on your page. Scripts, styles, images, fonts, iframes - you define the allowlist. Anything not on the list gets blocked.

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' https://cdn.trusted.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  frame-ancestors 'none'

What this does:

• default-src 'self' - by default, only load resources from your own domain.
• script-src 'self' https://cdn.trusted.com - scripts can only come from your domain or this specific CDN. An injected script from anywhere else is blocked by the browser before it executes.
• frame-ancestors 'none' - replaces X-Frame-Options, prevents clickjacking.

This is your XSS backstop. Even if an attacker injects a script tag into your page, if the script source isn't on your allowlist, the browser won't run it.

Why most teams don't implement it:

CSP is hard to get right, especially on established codebases. Inline scripts, eval usage and dynamically injected styles all conflict with a strict policy. The error messages aren't always helpful.

The right approach is to start in report-only mode:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-violations

This enforces nothing but logs every violation. You can see exactly what your existing codebase would break before you flip the switch. Run it for a few weeks, fix the violations, then move to enforcement.

At scale, CSP is not optional. It's the difference between a contained incident and a platform-wide compromise.

CORS - The Misconfigurations That Feel Like Security

CORS - Cross-Origin Resource Sharing - is widely misunderstood. Most developers encounter it as an error to fix, not a security mechanism to understand.

Here's the core idea: browsers block JavaScript from reading responses from a different origin unless that origin explicitly allows it. CORS headers on the server tell the browser what's permitted.

The misconfig that creates vulnerabilities:

Access-Control-Allow-Origin: *

This tells the browser any site can read responses from your API. For truly public, unauthenticated APIs this is fine. For an API that returns user data or accepts authenticated requests, this is a problem.

An even worse pattern:

// On the server - don't do this
const origin = req.headers.origin
res.setHeader('Access-Control-Allow-Origin', origin)
res.setHeader('Access-Control-Allow-Credentials', 'true')

This dynamically reflects whatever origin made the request and allows credentials. Effectively any site can make credentialed requests to your API and read the responses. This defeats the entire purpose of CORS.

The correct approach is an explicit allowlist:

const allowedOrigins = [
  'https://yourplatform.com',
  'https://app.yourplatform.com'
]

const origin = req.headers.origin
if (allowedOrigins.includes(origin)) {
  res.setHeader('Access-Control-Allow-Origin', origin)
}

CORS is not an authentication mechanism. It controls what the browser allows JavaScript to read. It does not stop direct requests made with curl, Postman or server-to-server calls. Your API still needs proper authentication and authorization regardless of CORS configuration.

What Developers Accidentally Break

The browser's security model is opt-out, not opt-in. Most of the protections are on by default. The problems happen when developers don't realize they're turning them off.

Using target="_blank" without rel="noopener"

Opening a link in a new tab with target="_blank" gives the new page a reference back to your page through window.opener. A malicious site opened this way can redirect your original tab.

<!-- Vulnerable -->
<a href="https://external.com" target="_blank">Link</a>

<!-- Safe -->
<a href="https://external.com" target="_blank" rel="noopener noreferrer">Link</a>

Modern browsers now default to noopener behavior for target="_blank", but it's still worth being explicit.

Disabling certificate warnings in development

Running your local dev server with a self-signed cert and clicking through browser security warnings trains developers to ignore those warnings. More importantly, configurations that disable certificate validation sometimes make their way into staging or production environments.

Putting secrets in frontend code

API keys, client secrets, internal endpoint URLs - these don't belong in frontend code. They end up in your JavaScript bundle, which is downloaded by every user and readable by anyone who opens DevTools. If a key needs to be kept secret, it belongs on the server.

Using eval() or new Function()

Beyond being a performance issue, eval executes arbitrary strings as JavaScript. If any user-controlled content reaches an eval call, it's an XSS vulnerability. CSP's script-src directive blocks eval by default for exactly this reason.

Final Thoughts

The browser is not your enemy. It's doing a significant amount of security work on your behalf, quietly on every page load. SameSite cookies, CORS restrictions, XSS escaping in frameworks, referrer policies - most of this just works if you don't interfere with it.

The job of a security-conscious frontend engineer is not to implement security from scratch. It's to understand what the browser already does, build on top of it and avoid accidentally disabling it.

At scale, that understanding is the difference between a platform your users can trust and one that's one misconfiguration away from an incident.

Know what the browser does for you. Don't get in its way.

Have thoughts or questions on frontend security? Drop them in the comments, always happy to discuss.

This article is part of the Frontend at Scale series.