Security

A lot of CORS bugs are really OAuth2 architecture bugs wearing a fake mustache. I’ve seen teams spend days tweaking Access-Control-Allow-Origin headers when the real problem was simpler: they were trying to run the wrong OAuth2 flow in the browser, or they expected the browser to carry cookies and tokens across origins in ways it never will. Here’s a case study based on a very normal setup: frontend: https://app.example.com API: https://api.example.com auth server: https://auth.example.com The team had a React SPA talking directly to the API. They wanted users to click “Login with OAuth”, get redirected to the auth server, come back with a session, and then call the API with fetch(). ...

I’ve heard developers say “I need to add CORS to my API for security” more times than I can count. That’s backwards. CORS doesn’t make your API more secure. In fact, it makes it less restricted. The security feature is the Same-Origin Policy. CORS is the controlled exception. Let me clear this up once and for all. Same-Origin Policy (SOP) The Same-Origin Policy is a built-in browser security mechanism. It’s been around since the early days of the web. Here’s what it does: ...

You’ve built a React frontend. You’ve built a Node.js API. They work perfectly when you test them separately. You wire them together, make your first API call, and… Access to fetch at 'http://localhost:3001/api/users' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Sound familiar? Every developer hits this wall. And most developers respond by Googling “how to fix CORS” and pasting app.use(cors()) without understanding what they just did. ...