Web-Security

CORS in Deno and Bun feels similar at first because both runtimes lean hard into the Web Platform. You get Request, Response, Headers, and fetch, so the mechanics are familiar. The difference shows up when you actually wire policies into a real server, especially once preflight requests, credentials, and route-level behavior enter the picture. My short take: Deno feels more explicit and standards-first. Bun feels faster to get running and very ergonomic, but you need to be just as disciplined about the policy because neither runtime magically saves you from bad CORS decisions. ...

CORS and CSRF get lumped together way too often. I’ve seen teams say “we enabled CORS, so we’re protected from CSRF now” and then act surprised when their app still has a cross-site request forgery bug. That’s the core mistake: these are not competing solutions to the same problem. They deal with different threats, at different layers, using different browser behavior. If you only remember one thing, make it this: ...

If you build a Rails API and your frontend runs on a different origin, CORS stops being theory pretty fast. You ship an endpoint, the browser blocks it, and suddenly everyone is staring at a console error that says “No ‘Access-Control-Allow-Origin’ header.” Rails itself does not magically solve CORS. You need to configure it intentionally, and if you get lazy with wildcards or credentials, you can open up more access than you meant to. ...

COOP and CORS get mixed together all the time, and I get why. They both have “cross-origin” in the name, both involve headers, and both can break your app in ways that feel random. But they solve different problems. CORS controls whether a page can read a cross-origin HTTP response in JavaScript. COOP, via the Cross-Origin-Opener-Policy header, controls whether a top-level document stays in the same browsing context group as pages it opens or pages that open it. That affects window.opener, popup relationships, process isolation, and features like SharedArrayBuffer when combined with other headers. ...

If you build APIs with FastAPI, you’re going to touch CORS almost immediately. Usually right after your frontend starts throwing blocked by CORS policy in DevTools and everyone suddenly becomes a browser networking expert. FastAPI makes CORS easy enough to turn on, but the hard part is choosing the right setup. There’s a big difference between “make the error go away” and “configure cross-origin access without creating a mess.” Here’s the practical comparison guide I wish more teams used. ...

If you build a frontend that calls Firebase Functions from a different origin, CORS stops being “that browser thing” and turns into a real deployment concern fast. Firebase gives you a few ways to deal with CORS, and they’re not equal. Some are clean and low-friction. Some are easy to misuse. Some look secure until you add credentials and realize you just shipped a broken policy. Here’s the practical comparison guide I wish more people had before copy-pasting Access-Control-Allow-Origin: * into every function. ...