Apache配置X-Frame-Options为DENY且响应头正常但iframe未被拦截

• 第一时间核对iframe实际加载的目标请求的响应头。很多人排查时看的是父级嵌入页面的响应头，没有切到Network面板选中iframe加载的具体资源单独校验。常见踩坑场景：Apache只给站点主目录的路由配置了安全头，iframe嵌的静态资源、子路由、独立端口的服务没有继承到头配置，等于被嵌的资源本身根本没返回X-Frame-Options: DENY，自然不会触发拦截。
• 排查浏览器的特殊放行规则：
  • 如果iframe加载的是localhost、127.0.0.1段的本地测试资源，Chrome会专门给本地开发场景放开部分安全头拦截逻辑，哪怕响应带了DENY也不会拦本地源的嵌入请求
  • 如果iframe加载的是about:blank、chrome-extension://开头的浏览器内置特殊源，X-Frame-Options规则本身就对这类地址不生效
• 检查响应头的格式有效性：
  • 确认Apache写的头值没有多余字符，比如尾部带空格、写法不规范，这类格式错误会让浏览器识别失败，直接跳过规则校验
  • 排查是否有重复的冲突头配置：如果Apache配置里同时写了好几组X-Frame-Options响应头，浏览器会优先执行第一个识别到的有效规则，后面的DENY配置会被覆盖忽略
• 核对Console面板的拦截报错。正常触发DENY拦截时，Chrome会明确输出Refused to display 目标地址 in a frame because it set 'X-Frame-Options' to 'deny'的报错。如果没看到这类报错，就能确定当前被加载的资源根本没带有效的DENY响应头，和预期的拦截逻辑对不上。

快速验证小技巧：单独在新标签页打开iframe加载的目标地址，切到Network面板找到这个请求，逐行核对响应头里X-Frame-Options的取值，一下就能找到配置偏差的位置。

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