“以前总觉得，只要后端把数据库守好，前端调用接口就是传个数据，能出什么事？”近日，一位拥有5年前端开发经验的工程师林浩（化名）在技术社区分享了自己的重构经历，引发广泛热议。他坦言，在为自己维护的一个中型Web项目逐步添加接口安全防护时，才发现此前应用的请求几乎处于“裸奔”状态——无加密、无校验、无防重放，攻击者只需一个浏览器开发者工具就能轻松篡改或窃取数据。
林浩的项目是一个面向C端用户的在线文档管理平台，日均API请求量超过50万次。在一次内部安全审计中，团队发现：所有接口虽使用了HTTPS，但前端请求体中包含的敏感字段（如用户ID、操作类型、时间戳）均为明文字段，且未对请求来源做任何校验。更令人后怕的是，部分涉及删除和修改的接口，竟没有CSRF防护。“换句话说，只要用户在一个恶意页面登录了我们的系统，攻击者就能伪造请求直接操作其文档，连密码都不需要。”林浩感叹。
痛定思痛，林浩在团队协作下，陆续为前端请求套上了6层保护机制。
第一层：传输加密双重化
基础HTTPS之外，所有请求体中的敏感字段使用AES-256加密。前后端约定临时密钥，每次登录后更新。林浩强调：“HTTPS只保证传输过程不被窃听，但服务器端或中间件日志可能记录明文数据，业务层加密是最后一道防线。”
第二层：来源校验（Referer + Origin双重验证）
服务端验证请求头中的Referer和Origin字段，只允许白名单域名发起请求。同时，前端在发送自定义请求头X-Requested-By: MyApp，服务端过滤非法来源。“很多框架自带CSRF中间件，但很多人会关闭，这是大忌。”
第三层：CSRF Token与签名相结合
除了传统Token校验，林浩引入基于时间戳和随机nonce的签名机制。每次请求携带签名，服务端校验通过后才放行。签名算法使用HMAC-SHA256，密钥存储在服务端环境变量中。“这能防止Token泄露后被批量利用，因为每个签名只能使用一次且有时效。”
第四层：参数强校验与白名单过滤
前端不再直接拼接用户输入，所有参数必须经过类型、长度、枚举值白名单校验。例如action字段仅允许create、delete等预设值，任何额外参数直接拒绝。服务端同样做二次校验，防止绕过前端检查。
第五层：接口频率限制与行为基线
每个用户每分钟请求数上限设为120次，超过则返回429。同时，服务端记录每个ID的“行为基线”：例如用户平均30分钟操作一次文档，若突然10秒内发起50次删除请求，立即触发告警并临时封禁。“这不是单纯防DDos，而是防恶意批量操作。”
第六层：防重放机制的“双保险”
请求中携带timestamp和nonce，服务端在Redis中存储5分钟内使用过的nonce，拒绝重复使用。即使攻击者截获完整请求包，也无法重放。“我曾以为HTTP协议天生幂等，但业务接口往往不幂等，重放攻击能直接导致数据不一致。”
六层防护上线后，林浩团队在测试环境中模拟了多种攻击场景：XSS、CSRF、重放、参数篡改，无一成功。“以前觉得这些防护‘过度设计’，直到看到拦截日志里每天有近千次来自外部IP的异常请求，才意识到裸奔有多危险。”他建议，中小团队至少应确保前三层防护落地，而每个开发者都应从“相信后端”转变为“前后端共同防御”的思维。
当前，前端安全常被视作“防御薄弱环节”。随着前后端分离与API经济的普及，接口层的威胁面正在扩大。林浩的经历提醒我们：在数字世界里，没有“裸奔”的侥幸，只有层层设防的安心。