🌐 CORS and CSP

Two Mechanisms, One Foundation

Browsers are hostile territory: every user has dozens of tabs open, any of which might be malicious. To keep sites from interfering with one another, browsers enforce the Same-Origin Policy. CORS and CSP are the two knobs that let you, the developer, adjust that policy deliberately:

• CORS (Cross-Origin Resource Sharing) — relaxes the policy so chosen origins can call your API
• CSP (Content Security Policy) — tightens it so your page only loads resources you approve

The Same-Origin Policy

An origin is the triple of protocol + host + port. Two URLs share an origin only if all three match exactly. Under the Same-Origin Policy, a script on one origin cannot read data from another origin — it can't read another site's cookies, its DOM, or the body of a cross-origin fetch.

Some cross-origin actions are allowed without reading the response: loading images, stylesheets, scripts, and iframes, and submitting forms. That's why a <script src> from a CDN works, but a fetch to that CDN's API needs CORS.

CORS: Cross-Origin Resource Sharing

When your front-end at app.example.com calls an API at api.example.com, the browser automatically adds an Origin header. The server decides whether to allow the read by echoing back an Access-Control-Allow-Origin header. If it's missing or doesn't match, the browser blocks your JavaScript from seeing the response.

# Browser automatically sends:
GET /api/data HTTP/1.1
Host: api.example.com
Origin: https://app.example.com

# Server chooses to allow this origin:
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://app.example.com
Content-Type: application/json

{ "data": "readable cross-origin" }

The key CORS response headers:

Preflight Requests

For "non-simple" requests — anything using PUT/DELETE/PATCH, a custom header like Authorization, or a JSON content type — the browser first sends a preflight: an automatic OPTIONS request that asks "am I allowed to make the real request?" Only if the server approves does the actual request go out.

# 1. Preflight (sent automatically by the browser)
OPTIONS /api/data HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization

# 2. Server approves the actual request
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

CORS in Express

Don't implement CORS by hand — use the well-tested cors middleware. Start restrictive and open up only what you need.

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

// ❌ Allows EVERY origin — fine for a fully public, cookieless API only
// app.use(cors());

// ✅ Allowlist specific origins, with credentials
app.use(cors({
    origin: ['https://app.example.com', 'https://admin.example.com'],
    methods: ['GET', 'POST', 'PUT', 'DELETE'],
    allowedHeaders: ['Content-Type', 'Authorization'],
    credentials: true,          // cookies allowed — so origin must NOT be '*'
    maxAge: 3600                 // cache preflight for 1 hour
}));

For dynamic allowlists (subdomains, env-driven config), pass a function. Crucially, reject unknown origins rather than reflecting them blindly:

const allowlist = new Set([
    'https://app.example.com',
    'https://admin.example.com'
]);

app.use(cors({
    origin(origin, callback) {
        // Allow non-browser tools (curl, mobile) that send no Origin
        if (!origin) return callback(null, true);
        if (allowlist.has(origin)) return callback(null, true);
        return callback(new Error('Not allowed by CORS'));
    },
    credentials: true
}));

Content Security Policy

Where CORS governs who calls you, CSP governs what your own page is allowed to load and run. It's the single most effective defense-in-depth against XSS: even if an attacker injects a <script>, a good CSP means the browser refuses to execute it.

You deliver it as the Content-Security-Policy HTTP header, a semicolon-separated list of directives, each naming approved sources.

app.use((req, res, next) => {
    res.setHeader('Content-Security-Policy', [
        "default-src 'self'",                          // fallback: same origin only
        "script-src 'self' https://trusted-cdn.com",   // where scripts may load from
        "style-src 'self'",
        "img-src 'self' data:",                         // allow inline data: images
        "connect-src 'self' https://api.example.com",   // fetch/XHR/WebSocket targets
        "object-src 'none'",                            // block <object>/<embed>
        "frame-ancestors 'self'"                        // anti-clickjacking
    ].join('; '));
    next();
});

Common directives and source keywords:

Nonces: safely allowing an inline script

Avoid 'unsafe-inline' — it defeats the whole purpose. When you truly need an inline script, generate a fresh random nonce per request and mark the script with it. An injected script won't know the nonce, so it's blocked.

const crypto = require('crypto');

app.use((req, res, next) => {
    const nonce = crypto.randomBytes(16).toString('base64');
    res.locals.cspNonce = nonce;
    res.setHeader('Content-Security-Policy',
        `default-src 'self'; script-src 'self' 'nonce-${nonce}'`);
    next();
});

// In your template (EJS):
// <script nonce="<%= cspNonce %>">/* allowed — carries the nonce */</script>

Report before you enforce

Roll CSP out safely with report-only mode: the browser reports what would be blocked without breaking anything, letting you tune the policy against real traffic first.

app.use((req, res, next) => {
    res.setHeader('Content-Security-Policy-Report-Only',
        "default-src 'self'; report-uri /csp-report");
    next();
});
app.post('/csp-report', express.json({ type: '*/*' }), (req, res) => {
    console.warn('CSP violation:', req.body);
    res.status(204).end();
});

CORS + CSP with helmet

In a real app you'll set CORS on the API and CSP (plus a dozen other headers) via helmet. Here they are together:

const express = require('express');
const cors = require('cors');
const helmet = require('helmet');
const crypto = require('crypto');
const app = express();

// Cross-origin access: allowlist only
app.use(cors({
    origin: ['https://app.example.com', 'https://admin.example.com'],
    methods: ['GET', 'POST', 'PUT', 'DELETE'],
    allowedHeaders: ['Content-Type', 'Authorization'],
    credentials: true
}));

// A fresh nonce per request
app.use((req, res, next) => {
    res.locals.nonce = crypto.randomBytes(16).toString('base64');
    next();
});

// Baseline secure headers + a tuned CSP
app.use(helmet());
app.use(helmet.contentSecurityPolicy({
    directives: {
        defaultSrc: ["'self'"],
        scriptSrc: ["'self'", (req, res) => `'nonce-${res.locals.nonce}'`],
        styleSrc: ["'self'"],
        imgSrc: ["'self'", 'data:', 'https://trusted-images.com'],
        connectSrc: ["'self'", 'https://api.example.com'],
        fontSrc: ["'self'", 'https://fonts.gstatic.com'],
        objectSrc: ["'none'"],
        frameAncestors: ["'self'"],
        upgradeInsecureRequests: []   // auto-upgrade http → https
    }
}));

app.listen(3000, () => console.log('Secured on :3000'));

Troubleshooting

Ninety percent of CORS and CSP bugs come down to a handful of messages. Learn to read them.

CORS: credentials not included

// Error: CORS header 'Access-Control-Allow-Origin' does not match / is missing
// Fix — server reflects the exact origin AND allows credentials:
//   Access-Control-Allow-Origin: https://app.example.com
//   Access-Control-Allow-Credentials: true
// ...and the client explicitly opts in:
fetch('https://api.example.com/data', { credentials: 'include' });

CORS: preflight 404

// The OPTIONS request isn't handled, so preflight fails before the real call.
// The cors() middleware answers OPTIONS automatically when applied globally.
// If you scope CORS per route, also handle preflight for it:
app.options('/api/data', cors());

CSP: blocked inline script

// Error: Refused to execute inline script because it violates the
//        Content Security Policy directive "script-src 'self'".
// Fix — add a nonce (NOT 'unsafe-inline'):
//   script-src 'self' 'nonce-abc123'
//   <script nonce="abc123">...</script>

Practice & Quiz

app.use(cors({
    origin: ['https://app.example.com', 'https://admin.example.com'],
    methods: ['GET', 'POST', 'PUT'],
    allowedHeaders: ['Content-Type', 'Authorization'],
    credentials: true,
    maxAge: 3600
}));

const policy = [
    "default-src 'self'",
    "script-src 'self' https://cdn.example.com",
    "style-src 'self'",
    "img-src 'self' data:",
    "object-src 'none'",
    "frame-ancestors 'self'"
].join('; ');
res.setHeader('Content-Security-Policy', policy);

Best Practices & Pitfalls

✅ Do

• Maintain an explicit origin allowlist; reject unknown origins
• Use the vetted cors and helmet middleware rather than hand-rolling headers
• Start CSP in report-only mode, then enforce once it's clean
• Prefer nonces or hashes over 'unsafe-inline'; set object-src 'none'
• Add frame-ancestors to block clickjacking and upgrade-insecure-requests

❌ Don't

• Combine Access-Control-Allow-Origin: * with credentials: true
• Reflect req.headers.origin back without checking it against an allowlist
• Reach for 'unsafe-inline'/'unsafe-eval' to "make CSP errors go away"
• Assume CORS is a server firewall — it's enforced by the browser, not your server

Summary

📚 Additional Resources

• MDN — Cross-Origin Resource Sharing (CORS)
• MDN — Content Security Policy (CSP)
• Express — cors middleware
• Helmet.js documentation
• OWASP — the attacks CSP and same-origin controls help mitigate

🚀 What's Next?

You've controlled who may talk to your API and what your pages may load. The remaining question is how much and how fast — throttling abusive traffic before it takes you offline. Next: Rate limiting and DDoS protection.