ERR_BLOCKED_BY_RESPONSE medium
net::ERR_BLOCKED_BY_RESPONSE (CORB/ORB/COEP cross-origin block)
The server answered, but Chrome discarded the response because it broke a cross-origin protection like CORP or COEP.
What you see
GET https://cdn.example.com/data.json net::ERR_BLOCKED_BY_RESPONSE.NotSameOrigin 200 (or in the console:) Cross-Origin-Resource-Policy prevented loading https://cdn.example.com/img.png
What’s actually happening
A script, image, font, or fetch fails even though the network tab shows a 200 from the server. Chrome appends a sub-reason after the dot that tells you which policy fired. The element that needed the resource breaks silently — a broken image, a font fallback, an iframe that never paints, or a fetch() that rejects. Firefox and Safari either allow the same request or report it as a generic CORS failure, so it often looks Chrome-specific.
Common causes
- The subresource is missing a Cross-Origin-Resource-Policy header and the page (or its top frame) sends Cross-Origin-Embedder-Policy: require-corp, so Chrome defaults the resource to same-origin and blocks it (reason: NotSameOriginAfterDefaultedToSameOriginByCoep).
- An <img>, <script>, or <link> on a COEP page loads a third-party URL that returns no CORP header and is requested without crossorigin, so it can't be vouched for (reason: CorpNotSameOrigin / CorpNotSameSite).
- ORB (Opaque Response Blocking, the successor to CORB) kills a no-cors response whose Content-Type is JSON, HTML, or XML when it was requested as a script or image — common when an API endpoint is loaded via <script src> or a misconfigured <img>.
- A document set Cross-Origin-Resource-Policy: same-origin on files that a different origin legitimately needs to embed.
- A cross-origin iframe inside a COEP document doesn't itself send COEP, so the frame load is refused (reason: CoepFrameResourceNeedsCoepHeader).
How to fix it
- Read the sub-reason after the dotThe string in DevTools is the diagnosis. NotSameOrigin / Corp* means a CORP header is missing or too strict; *ByCoep means COEP on the page promoted the resource to same-origin; CoepFrameResourceNeedsCoepHeader points at an iframe. Open the Network tab, click the blocked request, and check the Response Headers for an existing Cross-Origin-Resource-Policy value.
- Add a Cross-Origin-Resource-Policy header on the resource serverServe the embedded asset with Cross-Origin-Resource-Policy: cross-origin (or same-site if same registrable domain). In nginx: add_header Cross-Origin-Resource-Policy cross-origin; on the CDN/static origin, not the HTML page. This is the fix for the large majority of cases and does not require CORS.
- For ORB blocks, fix the MIME type or stop mislabeling the requestIf an endpoint returns JSON but is pulled in via <script src>, either change the consumer to fetch() it as JSON, or — if it really must be a script — return Content-Type: application/javascript. Don't serve text/html or application/json to a tag that expects executable script; ORB will keep dropping it.
- Reconcile COEP with the assets it pulls inIf the page sends COEP: require-corp, every cross-origin subresource must either send CORP or be loaded with crossorigin plus a CORS Access-Control-Allow-Origin response. If you don't actually need crossOriginIsolated (SharedArrayBuffer, high-res timers), drop the COEP header from the document and the blocks disappear.
- Verify with curl before and aftercurl -I https://cdn.example.com/data.json and confirm the Cross-Origin-Resource-Policy (and CORS) headers are present on the response, not just on the HTML. A header set on the page but missing on the asset origin is the usual trap.
Stop it recurring
Set Cross-Origin-Resource-Policy: cross-origin on every CDN/static asset origin by default, and only enable COEP on documents that genuinely need cross-origin isolation.
Related errors