如何保护同一服务器上供前端调用的Rest API端点安全？

不存在能覆盖所有风险的单一最优方案，业内通用做法是多层防护叠加，提升攻击者的破解成本到高于其获利阈值即可：

• 传输层基础加固 #

  强制全站启用HTTPS，从传输链路层面避免Bearer Token被中间节点明文拦截。Token存储与生命周期优化如下：
  1. 接口访问用的Access Token有效期设置为15~30分钟，泄露后可利用时间窗口限制风险
  2. 用于刷新Access Token的Refresh Token存入HttpOnly、Secure、SameSite=Strict属性的Cookie中，前端JS完全无法读取，从根源避免代码提取Token的风险
  3. 每次刷新Access Token时同步轮换Refresh Token，后端维护过期Refresh Token黑名单，发现泄露即可快速作废

• 请求合法性校验 #

  CORS规则不需要放弃，它的作用是限制浏览器端的跨域非法请求，能挡掉第三方页面恶意调用、普通浏览器插件偷请求的场景，本来就不是用来防curl这类手动伪造请求的工具。搭配签名校验机制补充防护：
  1. 前端每次请求将请求参数、当前时间戳、单次随机串nonce，用前后端约定的密钥生成签名放在请求头中
  2. 后端先校验时间戳是否在5分钟有效窗口内，再校验nonce是否已经被使用过，最后验签，三个条件都满足才处理请求，可完全防住重放攻击
  3. 签名密钥不要硬编码在前端静态代码中，每次页面加载时由服务端动态下发，每24小时自动轮换，就算攻击者爬取前端代码也拿不到长期有效的密钥

• 流量与风险管控 #

  1. 按IP、用户ID、客户端指纹维度做接口限流，超过阈值直接返回429状态码拒绝服务，挡住批量爬取、暴力遍历接口的行为
  2. 增加异常行为识别规则：比如无前端页面访问轨迹直接调用接口、短时间内批量遍历资源ID、请求参数格式异常的请求，直接要求人机验证或者临时拉黑对应IP

• 轻量化一次性令牌优化 #

  你提到的令牌环方案可以优化到完全无性能瓶颈：用JWT做一次性令牌，将允许访问的资源路径、请求方法、有效期、用户权限都存在JWT的Payload中，后端不需要存储令牌数据，只需要验证签名合法性即可。用户进入对应操作页时才下发对应操作的一次性令牌，有效期设置为1~5分钟，仅允许访问指定资源，用完即失效，就算泄露也无法滥用。

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