Blocked by response: X-Frame-Options, CSP, CORP and COEP fixes

What the error means

Chromium's source defines error -27 as a request that "failed because the response was delivered along with requirements which are not met", naming the X-Frame-Options and CSP ancestor checks and Cross-Origin-Resource-Policy. The server did answer: in our test the blocked frame arrived with status 200 and the browser threw it away.

Frames get the plain code. Images, scripts and no-cors fetches blocked by CORP get a suffix: .NotSameOrigin, .NotSameSite, or .NotSameOriginAfterDefaultedToSameOriginByCoep when your page's COEP forced the check. Inside a blocked frame, Chrome's error page says <host> refused to connect., Firefox says Firefox Can't Open This Page and suggests opening it in a new window, and WebKit leaves the frame empty.

Three lookalikes have other causes:

• net::ERR_BLOCKED_BY_CSP: your own page's CSP, for example frame-src 'none', blocked the frame.
• net::ERR_BLOCKED_BY_ORB: an img or script tag points at JSON or HTML from another origin.
• net::ERR_BLOCKED_BY_CLIENT: the browser or an extension chose to block the request.

Which header blocked it

ALLOW-FROM protects nothing: all 3 engines ignored X-Frame-Options: ALLOW-FROM http://127.0.0.1:8001 and loaded the frame, and MDN calls the directive obsolete. X-Frame-Options has no allow-list, so frame-ancestors is the way to allow named sites. When a response carried both X-Frame-Options: DENY and a frame-ancestors list with our origin, all 3 engines loaded the frame: frame-ancestors wins. It only works as an HTTP header; all 3 engines ignored it in a meta tag.

Ports count for same-origin. A page on http://localhost:8001 could not load an image from http://localhost:8002 sent with Cross-Origin-Resource-Policy: same-origin in any engine, while same-site loaded, because a site ignores the port. That is the usual local setup of a frontend and an API on two ports, and Express with helmet() 8.3.0 sends Cross-Origin-Resource-Policy: same-origin, X-Frame-Options: SAMEORIGIN and frame-ancestors 'self' by default.

What Firefox and Safari log

• X-Frame-Options: Firefox 155 logs The loading of "<url>" in a frame is denied by "X-Frame-Options" directive set to "deny". WebKit 26.6 logs Refused to display '<url>' in a frame because it set 'X-Frame-Options' to 'DENY'.
• frame-ancestors: Firefox logs Content-Security-Policy: The page's settings blocked the loading of a resource (frame-ancestors) followed by the directive. WebKit logs Refused to load <url> because it does not appear in the frame-ancestors directive of the Content Security Policy.
• CORP: Firefox logs The resource at "<url>" was blocked due to its Cross-Origin-Resource-Policy header (or lack thereof). WebKit logs Cancelled load to <url> because it violates the resource's Cross-Origin-Resource-Policy response header.
• COEP iframe: Chromium and Firefox print nothing in the Console. Chrome lists it under Issues, and its Network tab shows (blocked:COEP-framed resource needs COEP header) when the frame sends CORP without COEP. WebKit logs its CORP line or Refused to display '<url>' in a frame because of Cross-Origin-Embedder-Policy.

What JavaScript can see

The iframe load event fired for frames blocked by X-Frame-Options and frame-ancestors in all 3 engines, and reading iframe.contentWindow.location.href threw SecurityError whether the cross-origin frame loaded or not, so the embedding page can't tell the difference. If you control the framed page, have it postMessage the parent on load and treat silence as blocked: in our test the message arrived every time the frame loaded and never when it was blocked. For images onerror fires with naturalWidth 0, and a no-cors fetch() rejects with the generic TypeError; neither says why.

Fix it on the server that sends the header

1. Frames

   on the framed site, send Content-Security-Policy: frame-ancestors 'self' https://app.example.com, listing every origin allowed to embed it. Keep or drop X-Frame-Options; frame-ancestors overrides it.

2. Images, scripts and files

   on the server that serves them, send Cross-Origin-Resource-Policy: cross-origin, or same-site when both origins share a site. CORP does not apply to CORS requests: a fetch() in cors mode to a file with Access-Control-Allow-Origin: * and CORP same-origin returned 200 in all 3 engines.

3. Pages with COEP

   have the files send CORP cross-origin, or add crossorigin="anonymous" to the tag and send Access-Control-Allow-Origin from the file server, or switch to Cross-Origin-Embedder-Policy: credentialless, which Chromium and Firefox apply and WebKit 26.6 did not. A cross-origin iframe still needs its own COEP header plus CORP cross-origin; credentialless did not relax that. The Cross-Origin-Opener-Policy guide covers the isolation side.

import express from 'express';
import helmet from 'helmet';

const app = express();

// helmet() 8.3 defaults to X-Frame-Options: SAMEORIGIN, frame-ancestors 'self' and CORP same-origin
app.use(
  helmet({
    xFrameOptions: false,
    contentSecurityPolicy: {
      directives: { frameAncestors: ["'self'", 'https://app.example.com'] },
    },
    crossOriginResourcePolicy: { policy: 'cross-origin' },
  }),
);

app.get('/', (req, res) => res.send('<h1>Embeddable page</h1>'));

app.listen(3000, async () => {
  const response = await fetch('http://localhost:3000/');
  console.log({
    'x-frame-options': response.headers.get('x-frame-options'),
    'frame-ancestors': response.headers.get('content-security-policy').match(/frame-ancestors[^;]*/)[0],
    'cross-origin-resource-policy': response.headers.get('cross-origin-resource-policy'),
  });
});

# _headers in the publish directory (Netlify, Cloudflare Pages)
/embed/*
  Content-Security-Policy: frame-ancestors 'self' https://app.example.com

/images/*
  Cross-Origin-Resource-Policy: cross-origin

When you don't own the site

Without control of that server you can't embed the page. A proxy that strips X-Frame-Options or CSP isn't a fix: it breaks logins and cookies, and it is the pattern clickjacking uses. Link to the page so it opens in a new tab, as Firefox's own error page suggests, or fetch its HTML as text and render a preview. news.ycombinator.com sends X-Frame-Options: DENY and frame-ancestors 'self'; through https://proxy.cors.dev/ (free, no key, GET, text up to 1 MiB) its HTML came back with status 200 in all 3 engines.

// news.ycombinator.com sends X-Frame-Options: DENY, so we show its content instead of framing it
const target = 'https://news.ycombinator.com/';
const response = await fetch('https://proxy.cors.dev/' + target, { credentials: 'omit' });

if (!response.ok) {
  throw new Error(response.headers.get('X-Cors-Error') ?? `HTTP ${response.status}`);
}
const page = new DOMParser().parseFromString(await response.text(), 'text/html');
const stories = [...page.querySelectorAll('.titleline > a')].slice(0, 5).map((link) => ({
  title: link.textContent,
  url: new URL(link.getAttribute('href'), target).href,
}));
console.table(stories);

Good questions.