前后端分离项目接口安全防护完整方案

前后端分离架构下，接口安全不是靠单个方案就能解决的，它是一套贯穿请求链路、身份凭证、数据校验和服务端防护的组合策略。很多团队把接口安全简单理解为“加个token就行”，实际上攻击面远不止于此。下面直接拆解具体风险点和对应的防护手段，从身份认证、传输安全、参数校验、权限控制到限流审计，形成一套可以直接落地的完整方案。

前后端分离后，前端通常通过API与后端交互，传统Session-Cookie模式在跨域、集群部署和移动端适配上有明显短板。更合适的做法是采用JWT（JSON Web Token）作为身份凭证，但JWT本身不加密，因此必须配合HTTPS使用。JWT最大的问题是“签发后无法主动失效”，所以不能只存一个长期有效的token。建议采用“双token机制”：access_token有效期控制在15到30分钟，refresh_token有效期7到14天，并存储在服务端Redis中。当access_token过期时，前端携带refresh_token请求刷新接口，服务端校验Redis中的refresh_token是否有效且未被拉黑，通过后签发新的access_token。一旦用户修改密码、退出登录或账号异常，立即删除Redis中对应的refresh_token，使旧凭证全部失效。JWT的payload中只放用户ID、角色标识等非敏感信息，不要放手机号、邮箱等隐私数据。

全站启用HTTPS是底线，但仅仅在Nginx配置证书还不够。需要在服务端强制HTTP请求301跳转到HTTPS，并配置HSTS响应头，告诉浏览器在指定时间内只通过HTTPS访问该域名，防止首次访问被劫持降级。对于API接口，建议在Nginx层配置只允许TLS 1.2及以上版本，禁用不安全的加密套件。另外，如果前端页面存在混合内容（HTTP资源嵌入HTTPS页面），攻击者可以篡改这些资源进而窃取token。因此要在响应头中加入Content-Security-Policy，限制资源加载来源，同时设置X-Content-Type-Options: nosniff和X-Frame-Options: DENY，减少点击劫持和MIME嗅探风险。

前后端分离项目中，前端所有校验都可以被绕过，攻击者直接构造HTTP请求即可。服务端必须对每一个接口的入参做严格校验，包括数据类型、长度、范围、格式和业务逻辑合法性。例如用户ID必须是正整数，手机号必须符合正则，分页参数必须限制最大值。推荐使用统一的参数校验框架，在控制器层之前完成校验，避免在每个业务方法里重复写判断。对于JSON请求体，要限制请求体大小，防止超大报文消耗内存。对于文件上传接口，必须校验文件扩展名、MIME类型、文件头魔数和文件大小，并将文件存储在独立目录，重命名后返回访问路径，禁止直接使用用户提供的文件名拼接路径。

登录成功只代表用户“是谁”，不代表用户“能做什么”。很多越权漏洞的产生就是因为只做了认证，没有做授权。在接口设计阶段就要明确每个接口的权限要求，建议采用RBAC（基于角色的访问控制）模型，在网关层或中间件中统一做权限校验。对于水平越权，即用户A访问用户B的资源，必须在业务层校验资源归属。例如查询订单详情接口，不能只传订单ID，还要从当前登录用户上下文中取出用户ID，校验该订单是否属于当前用户。对于垂直越权，即低权限用户调用高权限接口，要在路由配置中标注所需角色或权限标识，中间件比对当前用户权限列表，不满足直接返回403。

即使token没有被窃取，攻击者也可能截获完整请求后原样重放。特别是支付、下单、修改密码等敏感接口，必须增加防重放机制。常用做法是在请求头中加入时间戳和随机数（nonce），服务端校验时间戳与服务器时间差不超过60秒，并将nonce存入Redis并设置60秒过期。如果同一个nonce在有效期内再次出现，判定为重放攻击，拒绝请求。对于特别敏感的接口，还可以要求前端对请求参数做签名，将参数按字典序排序后拼接密钥生成签名，服务端用相同算法验证签名，防止参数被篡改。

登录、注册、找回密码、发送短信验证码等接口是自动化攻击的重灾区。对于这些接口，不能只靠前端滑块或图形验证码，服务端必须接入验证码校验服务。建议在发送短信验证码前，先校验图形验证码或行为验证码，验证通过后再发送短信，并限制同一手机号60秒内只能发送一次，同一IP每天最多发送20条。登录接口连续失败5次后，锁定账号15分钟，并增加验证码难度。对于支付、提现、修改绑定手机等高风险操作，要求用户输入支付密码或进行二次身份验证，即使token泄露也无法直接完成操作。

接口限流不仅是防DDoS，也是防止单个用户或IP恶意刷接口。在Nginx层可以使用limit_req模块做基础的IP限流，例如每个IP每秒最多10个请求。在应用网关层，针对不同接口设置差异化限流规则，登录接口每秒每IP最多3次，普通查询接口每秒每用户最多20次。对于被限流的请求，返回429状态码和明确的错误信息。熔断机制则是在下游服务异常时快速失败，防止级联故障。当某个接口的错误率超过阈值时，自动打开熔断器，短时间内直接返回降级响应，避免大量请求堆积拖垮整个服务。

安全防护不能只靠拦截，还需要完整的日志用于事后追溯和异常分析。对于登录、注册、修改密码、支付、权限变更等关键操作，必须记录操作时间、用户ID、IP地址、操作类型、请求参数和响应结果。但日志中不能记录明文密码、token、短信验证码、银行卡号等敏感信息，需要对这类字段做脱敏处理，例如密码统一记录为“”，手机号中间四位打码。日志存储时间建议不少于180天，并限制日志文件的访问权限，防止攻击者通过日志获取敏感数据。同时要建立日志告警机制，当检测到短时间内大量失败登录、异常IP访问、权限变更等行为时，触发告警通知管理员。

前后端分离项目中，跨域请求是常态，但CORS配置不当会导致严重的跨域安全问题。如果后端设置Access-Control-Allow-Origin: *，并且允许携带凭证，那么任何网站都可以读取该接口的响应数据。正确做法是维护一个允许跨域的前端域名白名单，根据请求的Origin头动态判断是否在白名单内，只有在白名单内的域名才返回对应的Access-Control-Allow-Origin。同时，Access-Control-Allow-Credentials设置为true时，Access-Control-Allow-Origin不能为*，必须指定具体域名。对于不需要跨域的接口，直接不配置CORS头，从根源上杜绝跨域访问。

接口安全还包括数据本身的保护。用户密码必须使用强哈希算法存储，推荐使用bcrypt或argon2，并加入随机盐值，禁止使用MD5或SHA1。身份证号、银行卡号、手机号等敏感信息在数据库中可以加密存储，在接口响应中根据业务需要做脱敏返回。例如用户列表接口不需要返回完整手机号，只返回前三位和后四位。对于需要展示完整信息的场景，必须通过权限校验确认当前用户有查看权限。另外，接口响应中不要返回不必要的字段，例如用户表中可能包含密码哈希、内部状态等字段，在序列化时要排除这些字段，避免信息泄露。

随着业务迭代，旧版本接口可能存在已知漏洞或设计缺陷。建议在接口路径中加入版本号，例如/api/v1/user和/api/v2/user，当新版本上线后，旧版本进入废弃期，并在响应头中返回Deprecation提示。对于已经确认存在安全风险的接口，要有快速下线的能力，可以在网关层配置接口开关，紧急情况下直接返回404或410状态码。同时，定期对线上接口进行安全扫描和渗透测试，检查是否存在未授权访问、参数注入、敏感信息泄露等问题，将发现的问题纳入修复排期。

接口安全防护不是一次性工程，而是需要在开发、测试、上线、运维全生命周期中持续投入的工作。上述方案覆盖了从身份认证到数据保护的关键环节，每一层都可以独立实施，但只有组合起来才能形成纵深防御。对于中小团队，建议优先落地HTTPS强制跳转、服务端参数校验、JWT双token机制和接口级权限控制，这四项能挡住大部分常见攻击。之后再逐步完善限流、审计、防重放和敏感数据脱敏，最终形成一套完整且可持续演进的接口安全体系。