供浏览器端调用的无用户认证匿名REST API访问加固方案咨询

以下方案均针对「前端浏览器调用、无用户登录态、无法使用OAuth等用户令牌方案」的场景，核心思路是提升恶意调用的成本，最大程度过滤非法请求：

• 基础请求源校验
  服务端强制校验Origin、Referer请求头，仅放行自有业务域名的请求；可额外要求前端请求携带自定义头如X-App-Source: your_app_name，服务端同步校验，可直接拦截绝大多数无针对性的脚本爬虫请求。

• 请求签名防伪造
  前后端提前约定固定盐值与签名算法，前端请求时将请求参数、当前10位时间戳、盐值拼接后做SHA256哈希生成签名，请求时携带timestamp、sign两个字段。服务端先校验时间戳与服务器时间差不超过5分钟（拦截重放攻击），再用相同规则重新生成签名，与请求携带的签名对比，不一致直接拒绝。前端的签名算法、盐值需做代码混淆、字符串加密处理，提升逆向成本。

• 短时效匿名令牌机制
  用户首次打开Web应用时，前端先向服务端申请有效期15分钟以内的临时匿名令牌，令牌与请求客户端的IP、UA信息绑定。后续所有API请求必须携带该令牌，服务端校验令牌有效性、绑定的IP/UA是否匹配，过期后需重新申请。令牌申请接口本身需配置IP限流，避免被恶意刷取。

• 多层级限流拦截
  配置三层限流规则：1）单IP限流，同一个IP单位时间内的请求次数超过阈值直接拉黑一段时间；2）接口整体QPS限流，超过业务承载上限的请求直接拒绝，避免被批量扫库/刷接口；3）异常特征识别，对参数规律异常、UA异常的请求直接拦截。

• 前端代码防护
  对包含签名逻辑、盐值、令牌处理逻辑的JS代码做高强度混淆、反调试处理，增加攻击者逆向核心校验逻辑的成本。

注：所有前端侧下发的校验逻辑理论上都存在被逆向破解的可能，以上方案无法100%杜绝恶意调用，仅能提升攻击门槛，可根据业务风险等级组合使用，平衡安全与开发成本。

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