如何在iframe中打开页面？嵌入时出现不稳定跳转问题排查

1. 跨域iframe下的第三方Cookie拦截，触发应用预设的跳转死循环 #

你看到的返回内容 <html><script>window.location.href=window.location.href</script></html>，本身是很多业务系统内置的Cookie兜底种值逻辑：

• 原本的设计逻辑是：当应用检测到当前请求没有携带有效会话Cookie时，就返回这段自跳转脚本，让页面刷新一次，尝试触发浏览器种下会话Cookie，再加载正常业务页面
• 异常触发逻辑：当你的应用被嵌入第三方站点的iframe时，应用域的所有请求都属于浏览器定义的“第三方源”，当前主流浏览器默认会拦截第三方源的Cookie读取和写入（比如Chrome默认开启SameSite=Lax策略、Safari的智能防跟踪机制）：
  • 浏览器拦截第三方Cookie时，应用无法读取到有效会话Cookie，就会持续返回这段自跳转脚本，但脚本是在iframe上下文执行的，既没有权限操作顶层窗口完成刷新，又因为Cookie被拦截永远无法完成种值流程，最终用户只能看到这段代码，看不到正常页面
  • 部分用户可以正常打开页面，是因为这些用户之前直接以第一方身份访问过你的应用，浏览器已经存储了对应域的Cookie，系统会判定为非纯第三方请求，不会拦截Cookie读取流程
  • 禁用Cookie就可以正常加载，是因为你的应用存在分支判断：当检测到Cookie功能完全不可用时，会直接走匿名公开访问分支，不再触发那个种值刷新的逻辑，刚好绕过了死循环
  • 修改DNS、Nginx配置没有效果，是因为整个异常逻辑是应用层根据Cookie读取状态做的分支返回，和网络转发层没有关联

2. 帧嵌入安全校验的分支逻辑冲突 #

部分应用会针对嵌入场景做安全校验：

• 当请求携带有效会话Cookie时，会校验请求的Referer是否在允许嵌入的白名单范围内，如果校验不通过，就会返回这段自跳转脚本，试图把页面从iframe弹出到顶层重新完成安全校验
• 当Cookie被第三方拦截/用户主动禁用Cookie时，应用读取不到会话信息，就会跳过嵌入式白名单校验，直接返回正常页面，和你观测到的现象完全匹配

• 抓取异常场景下的完整请求、响应头，重点核对Set-Cookie字段的配置：如果没有加上SameSite=None; Secure属性，跨域iframe场景下的Cookie一定会被Chrome类浏览器拦截
• 检查应用的全局路由守卫逻辑，定位哪段代码会输出那段自跳转HTML，核对触发这段输出的前置判断条件，确认是否和“读取Cookie失败”的逻辑直接绑定
• 确认自跳转脚本的跳转目标：如果脚本里用的是当前iframe的window.location，就算Cookie配置正确，也无法在跨域iframe场景下完成Cookie种值，需要改成支持顶层跳转的window.top.location.href才能在iframe场景下正常生效

内容的提问来源于stack exchange，提问作者Lyubov Solodovnikova