The Core Difference
CORS and CSP are both browser security mechanisms enforced via HTTP headers, but they protect against entirely different threats:
CORS (Cross-Origin Resource Sharing) controls which origins can read responses from your server. It protects your API and data from being accessed by unauthorized websites.
CSP (Content Security Policy) controls which resources your page is allowed to load and execute. It protects your users from malicious content injected into your page (XSS attacks).
Think of it this way: CORS is about who can talk to your server. CSP is about what your page is allowed to do.
Threat Model Comparison
| CORS | CSP | |
|---|---|---|
| Protects against | Unauthorized cross-origin reads | XSS / content injection |
| Who is protected | Your server / API | Your users |
| Enforced by | Browser (on responses) | Browser (on page loads) |
| Configured on | The server being called | The page serving the HTML |
| Header direction | Response header from API | Response header from page |
How CORS Works
When a browser makes a cross-origin request (e.g., app.example.com fetching from api.example.com), it checks the response for Access-Control-Allow-Origin. If the header is absent or doesn’t match the requesting origin, the browser blocks the JavaScript from reading the response.
The request still reaches the server — CORS is not a firewall. It only controls whether the browser exposes the response to the requesting page’s JavaScript.
# Allow a specific origin to read responses
Access-Control-Allow-Origin: https://app.example.com
# Allow any origin (public APIs only)
Access-Control-Allow-Origin: *How CSP Works
CSP is a header sent with your HTML page that tells the browser which sources are trusted for scripts, styles, images, fonts, and other resources.
# Only load scripts from same origin and a trusted CDN
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.comIf an attacker injects <script src="https://evil.com/steal.js"> into your page via XSS, CSP blocks it from loading because evil.com is not in the allowlist.
Common Confusion
“I set CORS headers, so my site is secure” — CORS does nothing to prevent XSS. An attacker who injects a script into your page runs in your origin and bypasses CORS entirely (same-origin requests are never blocked by CORS).
“CSP will block my CORS requests” — CSP’s connect-src directive controls which URLs JavaScript can fetch. If your CSP doesn’t include your API origin in connect-src, the fetch will be blocked by CSP before CORS even applies.
“CORS prevents CSRF” — CORS does not prevent CSRF. Simple requests (forms, images) are not subject to CORS preflight. Use SameSite=Strict or SameSite=Lax cookies and CSRF tokens for CSRF protection.
Using Both Together
A well-secured application uses both:
- CORS on your API server — restrict
Access-Control-Allow-Originto your known frontend origins - CSP on your HTML pages — restrict
script-src,connect-src,img-srcto trusted sources - SameSite cookies — complement both by preventing cross-site cookie sending
Neither replaces the other. They operate at different layers and address different attack vectors.