ERR_BLOCKED_BY_RESPONSE: Which Header Blocked It and How to Fix

net::ERR_BLOCKED_BY_RESPONSE is Chromium error -27. Chromium defines it as a request that «failed because the response was delivered along with requirements which are not met (X-Frame-Options and Content-Security-Policy ancestor checks and Cross-Origin-Resource-Policy for instance)» (net_error_list.h). DNS, TCP, TLS and HTTP all succeeded: the response arrived over a working connection, and the browser then refused to use it because a header in that response forbids the way it was requested.

In practice the most common trigger is the first one, a page refusing to be put in an <iframe>, not the cross-origin-isolation family. It is not a certificate or HTTPS problem, not a CORS error (CORS failures are reported separately, as CORS errors in the console), and not a status-code problem.

Four mechanisms surface as the same network error, and the DevTools console message tells them apart. Read it before changing any header:

Two of these you cannot fix from your own site: X-Frame-Options and frame-ancestors are set by the site you are trying to embed, and they are a deliberate refusal. There is no client-side flag that overrides them.

These headers are often added by a layer you forgot about: a shared nginx snippet, a security-headers plugin, the application framework (Django's XFrameOptionsMiddleware sends DENY by default; WordPress sends X-Frame-Options: SAMEORIGIN on the login and admin screens), or a Cloudflare Transform Rule that modifies response headers. Find which layer adds the header before editing any of them. In nginx, hide the upstream's header and set the policy once for the path that must be embeddable:

location /embed/ {
    proxy_pass http://app;
    proxy_hide_header X-Frame-Options;
    add_header Content-Security-Policy "frame-ancestors 'self' https://partner.example.com" always;
}

# Public static files meant to be loaded by other sites
location /static/ {
    add_header Cross-Origin-Resource-Policy cross-origin always;
}

Remember that an add_header in a location block replaces all add_header directives inherited from the server level, so other security headers must be repeated there.

1. See what the response actually sends.

   curl -sI https://example.com/embed/page | grep -iE 'x-frame-options|content-security-policy|cross-origin'

2. Framing by a known partner: replace X-Frame-Options with CSP frame-ancestors listing the allowed origins. X-Frame-Options cannot list origins (the old ALLOW-FROM value is ignored by modern browsers), and when both headers are present, browsers that support frame-ancestors apply it instead of X-Frame-Options.
3. Resources loaded by other sites: set Cross-Origin-Resource-Policy: cross-origin on them. same-site blocks requests from another registrable domain (eTLD+1), and same-origin blocks even your own subdomains.
4. Cross-origin isolation (COOP + COEP): Cross-Origin-Opener-Policy: same-origin plus Cross-Origin-Embedder-Policy: require-corp is what unlocks SharedArrayBuffer, but every cross-origin subresource then needs CORP, or CORS via the crossorigin attribute and Access-Control-Allow-Origin. If you do not control those resources, use Cross-Origin-Embedder-Policy: credentialless, which loads no-cors resources without cookies instead of requiring CORP. Iframes on such a page must send COEP themselves.
5. Do not add COEP to fix this error. require-corp is a cause of ERR_BLOCKED_BY_RESPONSE, not a cure; only set it if you need cross-origin isolation.

Background on the headers: configuring CSP headers.

This is not on your side. The site you are viewing tried to embed or load something whose owner forbids that use, and the browser enforced the owner's instruction. Your clock, antivirus, DNS or network do not cause it, and clearing the cache will not help unless the browser is reusing a stale copy of an old response.

What you can do: open the blocked page directly in its own tab (framing rules do not apply to a top-level page), and tell the owner of the embedding site which widget is broken. Do not install extensions that strip security headers to make a frame load; they remove clickjacking protection on every site.

curl -sI https://example.com/embed/page | grep -i 'frame-ancestors'
# content-security-policy: frame-ancestors 'self' https://partner.example.com
curl -sI https://example.com/static/app.js | grep -i 'cross-origin-resource-policy'
# cross-origin-resource-policy: cross-origin

Then reload the embedding page with DevTools open and confirm the console no longer reports the block. To audit X-Frame-Options, CSP, CORP and the other response headers from outside, use the security headers checker.

• ERR_HTTP_RESPONSE_CODE_FAILURE — a non-2xx reached a caller that reads the status
• Content Security Policy — how CSP directives work
• How to check CORS — when the console reports a CORS error instead
• Mixed content — HTTP resources blocked on an HTTPS page
• ERR_EMPTY_RESPONSE — connection closed with no data