sfw/fix
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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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