AEM 6.5无头架构下如何保护页面、资产及内容API安全

Apache Sling Referrer Filter 方案可行性结论 #

这个方案不适合作为移动端内容API的核心身份校验手段，仅能作为辅助防护层使用，原因如下：

• Referrer是HTTP请求中可被任意篡改的客户端头字段，爬虫、脚本、调试工具都可以手动伪造任意Referrer值，直接绕过该过滤器的拦截规则
• 原生移动端应用发起请求时没有稳定的浏览器来源页属性，不同操作系统、不同Webview容器的Referrer生成逻辑差异极大，很容易出现合法移动端请求被误拦截的问题
• 该过滤器的设计初衷是防范CSRF跨站请求伪造攻击，定位是浏览器同源请求校验，从设计上就不承担跨端请求方身份识别的职能。

Adobe Granite OAuth 2.0 Server 场景适配性 #

该组件完全适配你的移动端内容保护场景，是AEM官方推荐的无头架构鉴权方案之一，落地逻辑非常清晰：

• 首先将你的React移动端应用注册为OAuth客户端，根据业务场景选择授权模式：如果内容需要用户登录后访问，走授权码模式对接你的用户体系；如果是公开无登录态的公开内容，走客户端凭证模式即可
• 移动端应用启动后先向AEM的OAuth令牌端点申请有效access_token，后续请求.model.json类内容接口时，在请求头携带Authorization: Bearer <token>
• AEM侧配置OAuth校验过滤器，令牌校验不通过的请求直接返回401状态码，即可拦截绝大多数非法调用
• 注意不要将客户端密钥硬编码在移动端安装包内，公开分发的应用建议搭配轻量令牌中转服务、设备指纹校验降低密钥泄露风险。

AEM无头架构下内容保护的全量可选方案 #

你可以根据自己的业务安全等级要求，组合选择以下方案：

网络层基础防护 #

• 在AEM前置的Dispatcher、CDN层配置IP白名单、专属UA校验规则，仅放行匹配你移动端出口IP段、携带应用专属UA标识的请求，作为第一道拦截防线。注意UA字段可被篡改，这层不能单独作为核心校验手段
• 如果是面向企业内部的移动端应用，可以直接接入VPN/零信任网关，仅允许接入企业可信网络的设备访问内容API

应用层签名校验（无登录态公开内容优先推荐） #

• 给移动端应用内置经过混淆处理的签名密钥，每次发起内容请求时，按照约定规则对请求路径、时间戳、设备唯一标识做哈希计算生成签名值，放在自定义请求头中传递
• 在AEM侧自定义Sling认证过滤器，依次校验三个维度：时间戳是否在有效窗口内（防重放攻击）、签名值是否和服务端计算结果一致、设备标识是否在异常黑名单中，全部校验通过才放行请求
• 该方案可靠性远高于单纯的Referrer、UA校验，落地成本低，适合不需要用户登录的公开内容场景

标准Token鉴权 #

• 即前面提到的Adobe Granite OAuth 2.0 Server方案，适合有用户登录体系的内容场景，可以支持按用户、按客户端粒度做精细化的内容权限控制
• 如果已经有自建的统一身份认证体系，也可以自定义Sling Authentication Handler对接自有身份服务，校验逻辑和内置OAuth方案完全一致

跨域规则辅助防护 #

• 配置Apache Sling CORS过滤器，仅允许你自有应用的来源跨域访问内容API，这层和Referrer Filter类似，仅适合作为Webview场景下的辅助防护，不能作为核心校验手段

内容层权限兜底 #

• 对敏感业务内容配置CUG（Closed User Group）访问权限，无论请求来源是什么，没有对应资源访问权限的请求一律拦截，作为内容安全的最后一道兜底

注意：所有可通过客户端逆向提取的校验规则（硬编码密钥、固定UA、固定Referrer等）都不能作为唯一的防护手段，建议至少组合两层以上校验规则，例如「CDN层基础校验 + 应用层签名/OAuth令牌校验 + 内容层CUG权限兜底」的组合，就能满足绝大多数移动端内容API的安全要求。

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