JS创建iframe加载YouTube报X-Frame-Options sameorigin报错如何解决

该X-Frame-Options拦截不存在纯前端修复方案。
X-Frame-Options是目标站点服务端返回的强制安全响应头，YouTube主站页面返回值为SAMEORIGIN，明确要求浏览器仅允许同域名页面嵌套自身内容，跨域名场景下浏览器会直接阻断iframe渲染。该校验逻辑由浏览器内核强制执行，前端代码无任何权限绕过。

采用新窗口内嵌iframe加载目标页的实现思路，本身不具备通用可用性，也无法达到隐藏浏览历史的预期：

• 主流高访问量站点（YouTube、Google、Meta系站点、国内主流电商/社交站点）普遍配置X-Frame-Options或CSP frame-ancestors规则，禁止第三方域名嵌套，该套代码对这类站点全部失效
• iframe加载的第三方资源依然会被记录在浏览器历史记录、网络请求日志、本地缓存中，完全无法实现隐藏搜索浏览历史的效果
• 多数站点自带防嵌套JS逻辑，会自主检测窗口层级，一旦发现自身被嵌套会直接将顶层窗口跳转到目标站点地址，打破页面隔离

现有实现代码如下：

function code(url) {
  var win = window.open();
  win.document.body.style.margin = '0';
  win.document.body.style.height = '100vh';
  var f = win.document.createElement("iframe");
  window.focus();
  // 目标URL已在函数入参中声明
  if (!url) return;
  f.style.width = "100%";
  f.style.height = "100%";
  f.style.border = 'none';
  f.style.margin = '0';
  win.document.body.appendChild(f);
  f.src = url
}

纯网页端无法完美实现预期效果，可选的合规实现路径共三类：

• 服务端代理方案：自建后端服务代理所有目标站点请求，过滤响应中X-Frame-Options、CSP相关响应头，同时替换页面内所有相对链接、资源路径为代理地址，再返回给前端iframe加载。该方案实现成本极高，需要处理目标站点反爬、登录态、动态内容加载问题，同时存在明确合规风险，未经授权代理第三方站点内容可能触发法律问题
• 调用浏览器原生能力：直接通过window.open引导用户在浏览器无痕/隐私模式下打开目标链接，无痕模式下的访问记录、缓存不会持久化到本地，是无兼容问题、合规的方案，无需嵌套iframe
• 浏览器扩展实现：如果交付形态为浏览器扩展，可申请对应扩展权限，使用浏览器提供的隔离浏览上下文、隐私模式API加载目标页面，该方式不会触发X-Frame-Options拦截，也能实现本地访问记录隔离，但需要用户提前安装对应扩展，无法在纯网页环境下实现

所有试图通过前端技巧绕过X-Frame-Options的方案（包括伪造请求头、修改iframe属性、利用srcdoc注入等）在2020年之后的现代浏览器版本中均已失效，无需在这类方向投入开发时间。

内容的提问来源于stack exchange，提问作者Kohen Webb