Security-Headers

Cross-Origin-Embedder-Policy sounds abstract until it blows up a working app. I’ve seen this happen on teams that enabled Cross-Origin-Embedder-Policy: require-corp to unlock SharedArrayBuffer, improve isolation, or satisfy a performance-heavy feature using WebAssembly. Everything looked fine in local dev. Then production started blocking scripts, workers, fonts, and random third-party assets that had worked for years. The root problem usually isn’t COEP by itself. It’s that COEP forces you to be honest about cross-origin resource loading. And that means CORS suddenly matters for resources your app used to “just load.” ...

Admin panels are where CORS mistakes get expensive. A marketing site with sloppy CORS might leak some harmless JSON. An admin panel with sloppy CORS can expose user data, internal actions, billing operations, or account management APIs to the wrong origin. I’ve seen teams treat CORS like a checkbox, copy a wildcard policy from a public API, and accidentally turn a privileged backend into something any website can talk 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. ...