新上线的API接口漏洞安全评审清单

新上线的API接口在进入生产环境前，必须经过一道严格的“安全评审”工序。这不是走形式，而是防止数据泄露、越权访问和业务逻辑被篡改的最后一道防线。很多团队把API安全评审等同于渗透测试，这是片面的。真正的评审清单应当贯穿设计、开发、测试和上线前四个阶段，覆盖从认证授权到数据脱敏的全链路。下面这份清单，就是直接可以落地的检查项，每一项都对应着真实业务中可能出现的致命漏洞。

API安全的第一道门是认证，但绝大多数漏洞出在“授权”上。检查清单的第一项，就是确认所有接口是否强制要求身份验证。这里不是看登录接口，而是看那些隐藏在业务流中的重置密码、导出数据、查看详情等接口，是否存在未授权访问的可能。具体操作上，直接抓取所有API端点，剥离Token或Session后重放请求，看是否返回200 OK。更隐蔽的漏洞在于水平越权和垂直越权。水平越权测试要准备两个同权限级别的账号A和B，用A的凭证去访问B的私有资源，比如订单详情、个人信息、聊天记录等，看接口是否仅依赖资源ID进行查询而忽略了归属校验。垂直越权测试则是用普通用户去调用管理员接口，或者相反。很多系统在后端只校验了用户是否登录，却没有校验角色权限，导致普通用户通过修改接口路径就能执行删除操作。JWT Token的校验逻辑也要单独审查，确认是否验证了签名算法、过期时间和签发者，防止通过none算法或弱密钥伪造Token。

API接口是直接暴露给客户端的，所有输入参数都不可信。SQL注入在API中依然常见，尤其是那些采用RESTful风格、路径参数直接拼接SQL的接口。检查时要在所有参数中插入单引号、双引号、反斜杠等特殊字符，观察返回包是否暴露出数据库错误信息。更值得关注的是NoSQL注入，在MongoDB或Redis场景下，传入$ne、$gt等操作符可能绕过查询逻辑。命令注入则多发于文件上传、图片处理、格式转换等接口，参数中拼接分号、管道符等系统命令分隔符，可能直接执行服务器命令。XML外部实体注入在SOAP接口或解析XML的REST接口中依然存在，通过构造外部实体可以读取服务器本地文件或发起SSRF攻击。每一项输入都要检查是否做了严格的类型校验和格式限制，比如手机号必须是纯数字且长度固定，邮箱必须符合正则，而不能仅依赖前端的表单验证。

API返回的数据结构往往比页面渲染时更完整，这就导致大量不该暴露的字段被直接返回给前端。检查时要用抓包工具查看每一个接口的响应体，确认是否返回了用户密码哈希、手机号、身份证号、银行卡号等敏感字段。即使前端不展示，只要数据传到了客户端，就能被截获。更隐蔽的是列表接口的ID自增问题，通过遍历ID就能爬取全量数据。还有一类常见漏洞是接口报错信息过于详细，直接返回了数据库表结构、服务器路径、框架版本甚至堆栈跟踪，这为攻击者提供了精准的攻击地图。文件上传接口要检查是否返回了文件的绝对路径，用户注册接口是否提示“手机号已存在”这类可被枚举的信息。所有敏感数据在传输层必须强制HTTPS，在应用层则要根据业务场景进行脱敏或加密存储，评审时要确认密钥管理方案是否安全，是否硬编码在代码中。

这是自动化扫描工具最难发现的漏洞类型，必须由熟悉业务的分析师手工审查。典型场景包括：优惠券接口是否可以被重复领取，通过并发请求是否能够突破每人限领一张的限制；支付回调接口是否验证了签名和订单状态，能否通过伪造回调直接修改支付状态；抽奖接口的概率是否由前端控制，修改请求包中的概率参数是否能百分百中奖；验证码接口是否在服务端校验，能否通过抓包获取验证码结果或绕过验证步骤直接请求后续接口。密码重置流程是重灾区，要检查重置令牌是否具有时效性、是否与用户绑定、使用后是否立即失效。批量操作接口如批量删除、批量导出，必须校验操作权限和数据范围，防止用户通过修改请求体中的ID列表操作他人数据。这类漏洞的评审需要对照业务需求文档，逐一推演正常流程和异常流程，找出逻辑上的断点。

没有速率限制的API等同于敞开大门任由攻击者暴力破解、撞库、爬取数据或发起拒绝服务攻击。评审时要确认登录、注册、发送短信验证码、密码重置等敏感接口是否设置了合理的频率限制，限制维度应当是用户ID、IP地址和设备指纹的组合，而非单一的IP限制。图形验证码和短信验证码的发送成本较高，必须在前端增加人机验证，并在后端限制同一手机号或IP的发送间隔和每日总量。对于需要消耗大量服务器资源的接口，如复杂报表导出、高清图片处理、全文搜索等，要检查是否设置了请求队列和超时熔断机制，防止单个用户的频繁请求拖垮整个服务。API的响应体大小也要有所限制，避免单次请求返回数百万条数据导致内存溢出。分页参数必须校验最大值，防止传入pageSize=999999进行拒绝服务攻击。

文件上传是获取服务器权限最直接的途径之一。评审清单必须覆盖文件类型校验方式，不能仅依赖客户端传来的Content-Type或文件扩展名，而应通过文件头魔数来判定真实类型。上传后的文件要存储在非Web可执行目录下，或者对脚本文件进行重命名和权限限制，防止上传一个PHP或JSP文件后直接被解析执行。文件内容也要进行病毒扫描和敏感内容检测，图片文件建议进行二次渲染以清除可能嵌入的恶意代码。文件下载接口则要防止路径遍历漏洞，通过../../etc/passwd这类参数读取服务器任意文件。下载路径必须做白名单限制，不能由用户直接指定文件路径，而应通过文件ID映射到实际存储位置。对于需要权限校验的下载接口，要确认是否每个请求都进行了身份验证，防止通过修改文件ID越权下载他人文件。

现代API很少是孤立运行的，它们依赖大量的第三方库、框架和内部微服务。评审时要拉取项目依赖清单，使用SCA工具扫描是否存在已知的高危漏洞，特别是那些被广泛利用的远程代码执行漏洞。依赖的版本不能停留在已停止维护的分支上。内部服务间的调用认证同样关键，很多团队对外部API做了严格鉴权，但对内网服务间的调用却完全信任，一旦攻击者通过SSRF打入内网，就能畅通无阻地调用所有内部接口。服务间通信必须启用双向TLS或采用统一的认证令牌，并遵循最小权限原则，每个服务只能调用它必需的接口。第三方API的回调地址也要做白名单校验，防止攻击者篡改回调地址接收敏感数据或伪造回调事件。

安全评审不仅要看预防措施，还要看事发后的追溯能力。所有敏感操作，包括登录、修改密码、修改绑定手机、转账、删除数据等，必须记录详细的操作日志，包含操作人、操作时间、操作IP、操作内容和操作结果。日志中严禁记录明文密码、完整银行卡号等敏感信息，需要进行脱敏处理。同时要检查日志的存储和访问权限，防止日志被篡改或删除。API网关或应用层应具备异常检测能力，对短时间内大量失败的请求、异常大的响应体、异常访问频率等行为进行实时告警。评审时要确认这些监控规则是否已配置并生效，告警通知是否能及时触达到运维人员。

CORS配置错误会导致恶意网站跨域读取用户敏感数据。评审时要检查Access-Control-Allow-Origin是否被设置为*，或者是否反射了请求中的Origin头而没有做白名单校验。Access-Control-Allow-Credentials为true时，Origin绝对不能是通配符，否则结合XSS漏洞可以直接窃取用户凭证。对于需要跨域携带Cookie的接口，要确认是否严格限制了允许的源域名，并且设置了合理的Access-Control-Allow-Methods和Access-Control-Allow-Headers，避免过度开放PUT、DELETE等危险方法。

代码层面的检查完成后，还需要对生产环境的配置进行最终确认。所有调试接口、测试后门、Swagger文档、Actuator端点等必须在生产环境中彻底关闭或进行严格的访问控制。默认的管理员密码、数据库密码、第三方服务密钥必须修改，不能使用框架或组件的默认值。HTTP方法要严格控制，对于只提供查询的接口，应当在服务器配置层面禁用PUT、DELETE、PATCH等方法。安全相关的HTTP头必须配置完整，包括Content-Security-Policy、X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security等，这些头部虽然不直接影响API逻辑，但能有效防御客户端的多种攻击。最后，整个评审过程要形成书面记录，每一项检查结果、发现的问题、修复方案和修复验证都要留存，作为系统上线审批的依据。