X-Permitted-Cross-Domain-Policies 头部配置踩坑实录

为啥要对比这几个方案？

最近在做安全策略配置的时候，被X-Permitted-Cross-Domain-Policies这个HTTP头部搞得有点懵。说实话，之前都是直接复制现成配置，没仔细研究过不同策略的区别。结果这次遇到一个跨域需求，发现不同的策略效果差得还挺多。

我比较喜欢把事情搞明白，所以今天就来对比一下各种cross-domain policies的实际效果。别提了，这个东西踩坑次数真的不少，每次都是改完配置后发现预期结果跟实际表现不一致。

四种策略的基本用法

先列出来四个常见的值：

• none – 完全禁止
• master-only – 只允许主策略文件
• by-content-type – 根据内容类型判断
• all – 全部允许

服务器端设置头部的代码大概是这样：

// Express.js 示例
app.use((req, res, next) => {
  res.setHeader('X-Permitted-Cross-Domain-Policies', 'master-only');
  next();
});

// PHP 示例
header('X-Permitted-Cross-Domain-Policies: by-content-type');

# Nginx 配置
add_header X-Permitted-Cross-Domain-Policies "none";

none策略 – 最严格的防守

none策略是最严格的，完全不允许跨域访问策略文件。这个在我做的金融类项目中经常用到，毕竟数据安全第一。

我比较喜欢用none的地方主要是纯内部系统的静态资源服务，比如管理后台的各种图标、XML配置文件这些。反正内部调用不需要考虑跨域，直接用none一劳永逸。

但是这个策略也有坑，就是一旦用了，所有外部Flash或者老版本浏览器的跨域请求都会失败。虽然现在Flash基本没人用了，但有时候还是会有历史遗留问题。

master-only – 我最喜欢的安全折中

master-only是我在大部分项目中选择的默认策略。只允许加载主策略文件crossdomain.xml，不允许其他跨域访问。

这个策略的好处是既保证了安全性，又给了一些灵活性。比如我之前做过一个在线编辑器项目，需要加载一些外部字体文件，用master-only就刚刚好。

<!-- crossdomain.xml 示例 -->
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <site-control permitted-cross-domain-policies="master-only"/>
    <allow-access-from domain="*.myapp.com" secure="true"/>
</cross-domain-policy>

不过需要注意的是，用了master-only之后，如果你的crossdomain.xml文件本身有问题，那所有的跨域请求都会失败。我之前踩过一次坑，crossdomain.xml语法错误导致整个系统都受到影响。

by-content-type – 灵活但危险的选择

by-content-type这个策略比较特殊，它根据响应的内容类型来决定是否允许跨域。说实话，这个策略我很少用，因为它太复杂了，而且容易出现意外情况。

按道理说，这个策略应该允许图片、CSS、JS等非敏感资源的跨域访问，但阻止XML、JSON等数据类型的跨域请求。但实际上，有些时候Content-Type头会被错误设置，就会导致安全漏洞。

我记得有一次用CDN加速图片，结果CDN返回的Content-Type是application/octet-stream而不是image/jpeg，这就导致图片被当成了数据文件，不允许跨域访问。调试了半天才发现是这个策略的问题。

all策略 – 完全开放，风险最高

all策略就是完全开放跨域访问，基本上等于没设安全策略。这个策略我只在开发环境或者完全公开的API服务中用过。

比如做一些公开的数据展示页面，需要从多个源加载资源，用all确实最简单。但是生产环境下基本不敢用，除非确认所有暴露的资源都是公开的，没有敏感信息。

这个策略的坑在于，一旦用错了环境，安全风险非常大。我之前有个同事不小心在生产环境中配了all，结果第三方站点可以直接读取我们的一些接口数据，还好及时发现了。

性能对比：其实差距不大

从性能角度看，这些策略的差异基本可以忽略。毕竟只是一个HTTP头部，解析成本很低。不过by-content-type稍微复杂一点，因为需要检查Content-Type头，理论上会有微小的性能损耗。

我在做压力测试的时候专门对比过，在QPS几千的情况下，不同策略之间的响应时间差异都在毫秒级别，完全可以忽略不计。

谁更灵活？谁更省事？

从灵活性来说，by-content-type肯定是最灵活的，可以根据不同内容类型做精细化控制。但从实用性来说，我觉得master-only更合适。

为什么这么说？因为master-only既能满足大部分业务需求，又避免了by-content-type的复杂性和潜在风险。none太严格，all太宽松，master-only刚好平衡了安全性和可用性。

至于省事程度，none和all是最省事的，直接设置就行。master-only需要配合crossdomain.xml文件，稍微麻烦一点，但这是值得的。

我的选型逻辑

经过多次项目实践，我现在有了一套相对固定的选型标准：

对于内部管理系统、金融类应用，直接用none，安全第一。

对于对外提供服务的应用，优先选择master-only，配合合理的crossdomain.xml配置。

只有在确定没有敏感数据且需要高度灵活性的情况下，才会考虑all。

by-content-type我是尽量避免使用的，除非有特殊的业务需求并且充分评估了风险。

其实大多数情况下，none和master-only就能覆盖90%以上的使用场景。搞得太复杂反而容易出问题，现在的浏览器安全机制已经很完善了，不需要过度依赖这些古老的策略文件。

踩坑提醒：这三点一定要注意

首先，设置了X-Permitted-Cross-Domain-Policies之后，一定要记得同时配置CORS头部，两者并不冲突，但作用不同。

其次，crossdomain.xml文件的位置很重要，必须放在根目录下，并且路径固定，不能随便更改。

最后，测试的时候一定要用真实的跨域场景，不要只在同域环境下测试，那样看不出策略的效果。

实际部署中的问题

在真实项目中，我还遇到过一个有趣的问题。某个CDN服务商不支持自定义X-Permitted-Cross-Domain-Policies头部，导致我们无法在CDN层面设置安全策略。

最终的解决方案是在源站设置策略文件，CDN缓存一份。这样既保证了CDN的加速效果，又维持了安全策略。但要注意缓存时间的设置，策略文件更新时需要及时刷新CDN缓存。

另外，HTTPS环境下有些浏览器对策略文件的要求更严格，secure=”true”这个属性必须加上，不然会被拒绝。

以上是我对X-Permitted-Cross-Domain-Policies不同策略的对比总结，有不同看法欢迎评论区交流。