API-Security-Checklist：设计、测试与发布 API 的安全核对清单全解析

网络安全应用安全【免费下载链接】API-Security-ChecklistChecklist of the most important security countermeasures when designing, testing, and releasing your API项目地址https://gitcode.com/gh_mirrors/ap/API-Security-Checklist点击查看免费下载本文以开源仓库 API-Security-Checklist 的官方清单为蓝本围绕仓库中的印地语版本 README-hi.md 逐章展开覆盖从身份认证、访问控制到监控告警的全部核对条目并对照英文原版 README.md 与中文版 README-zh.md 补齐细节。读完本文你将获得一份可直接嵌入团队评审、安全自查与 CI 发布门禁的完整行动清单知道每一项检查防的是什么攻击、为什么必须做、大致怎么落地。一、认识这份清单可逐项执行的 API 安全对抗手册1.1 项目定位API-Security-Checklist 是一份面向 API 设计、测试与发布全流程的最重要安全对抗措施核对清单对应英文原版开篇所述Checklist of the most important security countermeasures when designing, testing, and releasing your API。它不绑定任何具体编程语言或框架而是把安全要求抽象成约 50 条可勾选的检查项按攻击面与工程阶段分组供团队在上线前逐条自查。1.2 仓库结构与使用方式从仓库结构看这是一个纯文档型仓库不含可执行源码或示例工程主体是 31 份 README 文件英文原版 README.md 加 30 种语言的翻译版以及 CONTRIBUTING.md 贡献指南与 LICENSEMIT 协议版权归 Shieldfy 团队。清单本身不提供代码实现每一条都需要由使用方在自己的技术栈中落地——这正是它的定位一份评审清单而非一份框架文档。实用用法很简单把- [ ]逐项当作发布门禁每一项都要在评审会上拿出实现方式 验证证据全部勾选后才能上线。你也可以把这份清单转成团队内部的测试用例、安全扫描配置或评审模板。二、身份认证Authentication不造轮子且让登录可冻结清单原文不要使用 Basic Auth请改用标准认证协议。不要在认证、令牌生成、密码存储上重复造轮子请使用标准方案。登录功能要设置最大重试次数Max Retry并加入锁定jail机制。对所有敏感数据使用加密。逐项解读禁用 Basic AuthBasic Auth 把用户名:密码仅做 Base64 编码后放进每个请求头既不加密也没有令牌过期机制一旦被中间人截获或日志泄漏等同于凭证直接暴露。应改用 OAuth 2.0、OpenID Connect 等标准认证协议由认证服务器统一颁发、刷新与撤销凭证。认证、令牌生成、密码存储全部用标准实现这三处是安全攻防的高发区自研极易出错。密码存储应使用带盐的慢哈希算法如 bcrypt、scrypt、Argon2 一类的设计思路令牌生成应使用成熟标准库避免自己拼接随机数或实现签名逻辑。Max Retry jail重试上限与锁定这是对抗在线暴力破解与撞库的核心手段。实现上通常包括同一账号/来源连续失败 N 次后临时锁定锁定期间拒绝登录同时配合后文输入章节的限流策略从账号维度和 IP 维度双重收敛攻击面。加密所有敏感数据覆盖静态与传输两个层面——传输层依赖 TLS见访问章节存储层需要对数据库字段、备份文件、对象存储中的敏感内容做加密避免数据库泄露即等于明文泄露。三、访问控制Access限流、传输加密与暴露面收敛清单原文限制请求频率Throttling以防范 DDoS / 暴力破解攻击。服务端使用 HTTPS 以避免 MITM中间人攻击。英文原版 README.md 进一步补充使用 TLS 1.2 与安全密码套件并确保Host头与 SNI 匹配。配合 SSL 使用 HSTS 响应头防范 SSL Strip 攻击。关闭目录列表。私有 API 仅允许白名单 IP/主机访问。逐项解读限流Throttling对单位时间内的请求量做上限控制是抵御 DDoS 洪泛和暴力破解的兜底手段。可在 API 网关层按 IP、账号、API Key 维度分别限流更精细的做法见后文进阶实践限流与滥用防护。服务端 HTTPS全链路 TLS 加密防止中间人窃听与篡改。注意两点细节一是协议版本与密码套件要跟上安全基线TLS 1.2、禁用弱套件二是服务器要校验Host头与 SNI 一致防止基于域名混淆的绕过。HSTS 防 SSL StripHSTS 响应头如Strict-Transport-Security: max-age31536000; includeSubDomains强制浏览器只通过 HTTPS 访问该域堵住先降级到 HTTP 再篡改的 SSL Strip 攻击路径。关闭目录列表Web 服务器默认的目录浏览功能会暴露文件结构、备份文件、配置文件路径必须全局关闭同时注意静态文件托管如对象存储、CDN也不要开放目录列举。私有 API 白名单仅限内部使用的 API 应放在私有网络或加 IP/主机白名单从网络层就拒绝非授权来源的访问而不是依赖应用层判断。四、授权Authorization与 OAuth把授权流程焊死清单原文始终在服务端校验redirect_uri仅允许白名单中的 URL。始终使用授权码换取令牌code exchange不允许response_typetoken。使用带随机哈希的state参数防止 OAuth 授权流程中的 CSRF。定义默认作用域default scope并对每个应用校验 scope 参数。逐项解读服务端校验redirect_uriredirect_uri是授权回调地址攻击者常利用未校验的回调地址把授权码重定向到自己的站点。必须由服务端将其与预先注册的白名单 URL 做精确比对而非前端校验杜绝开放重定向。授权码模式而非隐式模式授权码流程Authorization Code Flow中客户端拿到的是一枚短生命周期、一次性使用的 code再用 code 与服务端换取 access_token隐式模式response_typetoken直接把令牌暴露给浏览器令牌易被窃取因此清单明确禁止。state参数防 CSRFOAuth 授权流程中攻击者可以诱导已登录用户访问一个带攻击者参数的授权链接从而把受害者的授权结果绑定到攻击者发起的请求。客户端应生成随机state值并在回调时校验其一致性阻断该攻击链。默认 scope 按应用校验为每个应用定义最小化的默认 scope并在授权时校验应用请求的 scope 是否在允许范围内避免应用请求超出其所需的权限过度授权。五、输入Input在入口处拦截大部分攻击清单原文根据操作使用正确的 HTTP 方法GET读取、POST创建、PUT/PATCH替换/更新、DELETE删除如果请求的方法不适用于目标资源应返回405 Method Not Allowed。校验请求Accept头的content-type内容协商只允许你支持的格式如application/xml、application/json等不匹配时返回406 Not Acceptable。校验提交数据的content-type是否为你接受的类型如application/x-www-form-urlencoded、multipart/form-data、application/json等。校验用户输入避免常见漏洞如XSS、SQL 注入、远程代码执行等。不要在 URL 中使用任何敏感数据credentials、Passwords、security tokens、API keys应使用标准的 Authorization 请求头。仅使用服务端加密。使用 API 网关服务启用缓存、限流策略如Quota、Spike Arrest、Concurrent Rate Limit并支持动态部署 API 资源。逐项解读HTTP 方法语义化让接口严格区分读、写、改、删语义并用405拒绝非法方法既符合 REST 规范也能让网关与 WAF 按方法做策略匹配缩小攻击面。内容协商双重校验一是响应侧——客户端Accept头声明能接收的格式服务端只返回白名单格式不满足就回406二是请求侧——校验 POST 正文的content-type声明与解析方式一致。双重校验可避免声明 JSON 实际传 XML这类解析器混淆导致的注入类问题。输入校验对所有用户可控输入参数、正文、文件、请求头做白名单校验与转义是防 XSS、SQL 注入、命令注入、反序列化攻击等 OWASP 常见漏洞的第一道防线校验应在服务端进行前端校验只改善体验不能作为安全边界。敏感数据不进 URLURL 会进入访问日志、浏览器历史、Referer 头、代理与 CDN 日志把 API Key、密码、令牌放进 URL 等于把凭证散播到各处。凭证应放在Authorization请求头中并配合 TLS 传输。仅服务端加密加解密密钥与流程必须由服务端控制。前端参与密钥管理或加密逻辑既不可信也无法保密且会让密钥随客户端分发而泄露。API 网关统一管控把缓存、限流Quota配额、Spike Arrest尖峰抑制、Concurrent Rate Limit并发限流与 API 资源的动态部署集中到网关层让流量治理与安全策略同层生效后端服务得以保持简单。六、处理Processing业务逻辑层的安全细节清单原文检查所有端点是否都位于认证之后避免认证体系被绕过broken authentication。避免使用用户自有的资源 ID用/me/orders替代/user/654321/orders。不要使用自增 ID改用UUID。如果解析 XML 数据确保实体解析entity parsing未启用以避免XXEXML 外部实体攻击。如果解析 XML 等带锚点与引用的格式确保实体扩展entity expansion未启用以避免通过指数级实体扩展实现的Billion Laughs/XML bomb攻击。英文原版 README.md 进一步把该条扩展到 YAML 及其他支持锚点/引用的语言。文件上传使用 CDN。处理海量数据时尽可能使用 Workers 和队列在后台处理快速返回响应避免 HTTP 阻塞。别忘了关闭 DEBUG 模式。可用时使用不可执行non-executable的栈。逐项解读全端点认证覆盖上线前逐一对路由清单做未认证可达性检查防止新加接口忘了挂在认证中间件后面导致出现未授权访问的旁路。资源归属与越权/user/654321/orders这类客户端直接指定他人资源 ID的接口是越权IDOR的高发地。改用/me/orders让资源归属由会话/令牌推导而非客户端指定从设计上消除水平越权同时仍要在服务端对每次资源访问做归属校验。UUID 替代自增 ID自增 ID 可被枚举、泄露业务规模信息还容易成为批量抓取与遍历攻击的抓手使用 UUID 让资源标识不可预测。XXE 与 Billion Laughs解析 XML 时实体解析开启会让攻击者借助外部实体读取服务器本地文件XXE实体扩展开启则可能通过嵌套实体指数级放大解析量耗尽内存Billion Laughs/XML bomb。应对方案是显式关闭 DTD/实体解析与实体扩展同理YAML 等支持锚点和引用的序列化格式也存在类似的指数扩展风险需在解析器配置中一并限制。文件上传走 CDN把用户上传文件放到 CDN/对象存储并做内容与类型校验避免直接写入应用服务器磁盘造成存储耗尽、路径穿越或恶意文件被同源执行。后台化重活大计算量、大 IO 操作应放入 Workers/队列异步处理主请求快速返回已受理状态避免长时间占用 HTTP 连接导致阻塞型 DoS。关闭 DEBUGDEBUG 模式会输出堆栈、SQL、配置与内部路径生产环境必须关闭否则等于把调试信息直接送给攻击者。不可执行栈在操作系统/运行时支持的前提下启用 NX/ASLR 等防护提高内存破坏类漏洞如栈溢出、ROP的利用成本。七、输出Output不让响应泄露任何信息清单原文发送X-Content-Type-Options: nosniff响应头。发送X-Frame-Options: deny响应头。发送Content-Security-Policy: default-src none响应头。移除指纹头X-Powered-By、Server、X-AspNet-Version等。强制响应content-type如果返回application/json则响应的content-type必须是application/json。不要向客户端返回过于具体的错误信息会暴露实现细节应使用通用消息详细日志只保留在服务端。不要返回敏感数据如credentials、Passwords、security tokens。根据完成的操作返回正确的状态码如200 OK、400 Bad Request、401 Unauthorized、405 Method Not Allowed等。逐项解读三个安全响应头X-Content-Type-Options: nosniff禁止浏览器对响应做 MIME 嗅探阻断上传伪装文件被当脚本执行类攻击X-Frame-Options: deny禁止页面被 iframe 嵌入防点击劫持Content-Security-Policy: default-src none收紧内容来源是 XSS 的纵深防线。可在 Web 中间件/网关统一追加X-Content-Type-Options: nosniff X-Frame-Options: deny Content-Security-Policy: default-src none Strict-Transport-Security: max-age31536000; includeSubDomains移除指纹头X-Powered-By、Server、X-AspNet-Version等头会暴露技术栈与版本为攻击者筛选漏洞库提供情报应在反代层剥离或改写为通用值。content-type 与正文一致响应声明application/json就必须返回规范的 JSON并做 JSON 转义防止把未转义的富文本、HTML 片段混入 JSON形成内容类型混淆型 XSS。错误信息最小化客户端只应看到请求失败级别的通用提示具体的堆栈、SQL、内部路径等细节一律只在服务端日志中记录避免错误响应成为信息泄露通道。不返回敏感数据接口返回体的字段要按最小必要裁剪避免把密码哈希、令牌、内部标识、第三方凭证等随业务响应一起返回。正确的状态码用状态码精确表达语义——成功用200 OK参数错误用400 Bad Request未认证用401 Unauthorized方法不符用405 Method Not Allowed。既避免语义混淆带来的逻辑绕过也方便监控与告警按状态码分类。八、持续集成与持续部署CI CD把安全检查自动化清单原文用单元测试/集成测试的覆盖率来审计你的设计与实现。使用代码评审流程并禁止自我批准self-approval。在推送到生产环境前确保服务所有组件都被杀毒软件静态扫描包括第三方库和其他依赖。持续对代码运行安全测试静态/动态分析。检查依赖软件与操作系统是否存在已知漏洞。为部署设计回滚方案。逐项解读测试覆盖率兜底单元与集成测试不仅要覆盖正常路径还要覆盖认证、鉴权、限流、输入校验等安全路径让清单条目转化为可回归的测试用例。代码评审 禁止自我批准安全改动必须由他人评审把关。仓库的 CONTRIBUTING.md 同样明确了 Pull Request 评审纪律一次 PR 只做一件事、提交历史清晰、同步最新主干安全评审可以沿用同一套流程约束。组件静态扫描上线前对应用自身与全部第三方依赖做病毒/恶意代码静态扫描防止供应链投毒进入生产。持续安全测试把 SAST静态应用安全测试与 DAST动态应用安全测试接入 CI 流水线每次提交都自动执行让安全问题在合入前暴露。依赖漏洞检查对应用依赖与底层操作系统软件包持续比对已知漏洞库如 CVE 数据并建立升级与告警机制。回滚方案为每次部署准备可快速回退的机制镜像版本保留、蓝绿/金丝雀、数据库迁移回滚等一旦线上出现安全异常能第一时间恢复到上一安全版本。九、监控Monitoring可观测、可告警、可追溯清单原文对所有服务和组件使用集中式日志centralized logs。使用代理agents监控所有流量、错误、请求和响应。使用告警短信、Slack、Email、Telegram、Kibana、Cloudwatch 等。确保没有记录任何敏感数据如信用卡、密码、PIN 等。使用 IDS 和/或 IPS 系统监控你的 API 请求和实例。逐项解读集中式日志把各服务的日志汇聚到统一平台才能跨服务追踪请求链路、排查越权与异常调用同时要配套日志的访问控制与留存策略。全量流量监控通过代理/采集器记录流量、错误、请求与响应形成谁在什么时间调了哪个接口的审计事实这是事后溯源和事前发现异常行为的基础。多通道告警按严重级别接入短信、Slack、Email、Telegram、Kibana、Cloudwatch 等通道让安全事件不被淹没在噪声里。日志脱敏日志里绝不能出现信用卡号、密码、PIN 等敏感数据——日志一旦泄露就等同凭证泄露。应在写日志前对敏感字段做结构化脱敏或直接剔除。IDS/IPS 部署在网络层部署入侵检测/防御系统监控 API 请求与实例对扫描、异常流量、已知攻击特征做实时拦截。十、进阶实践限流与滥用防护Rate Limiting Abuse Prevention清单原文针对每个 API Key 和 IP 实现滑动窗口限流。对反复失败的认证尝试使用指数退避exponential backoff。在可疑活动后加入 CAPTCHA 或工作量证明proof-of-work挑战。监控并告警异常 API 使用模式时间、量级、端点。逐项解读滑动窗口限流相比固定窗口在边界处的重置即放开滑动窗口按 API Key 与 IP 双维度统计连续时间窗内的请求量能平滑抑制突发流量兼顾用户体验与防滥用。指数退避对连续失败的登录/认证请求逐步加大间隔与锁定时间让暴力破解的成本随尝试次数指数上升而不是恒定速率地尝试。挑战机制当检测到可疑行为高频失败、异常流量时用 CAPTCHA 或工作量证明增加自动化攻击的成本把正常用户与脚本机器人区分开。异常模式告警持续监控调用时间分布、总量波动与端点热度识别爬取、撞库、API 资源滥用等模式并触发告警。十一、进阶实践GraphQL 专属安全GraphQL-Specific Security清单原文在生产环境禁用 introspection内省查询。实现查询深度限制防止嵌套查询攻击。使用查询成本分析防止资源耗尽。生产环境尽可能白名单允许的查询。逐项解读禁用 introspectionGraphQL 的内省能力会把完整 Schema 暴露给任意查询者等于公开全部数据模型与字段生产环境必须关闭。查询深度限制GraphQL 允许嵌套查询攻击者可构造几十层嵌套的查询让服务端递归展开形成复杂查询 DoS限制最大查询深度是基础防线。查询成本分析按字段解析开销、返回数据量对查询做成本估算超出预算直接拒绝防止单条查询拖垮后端资源。查询白名单对稳定的生产查询做持久化/白名单只允许预注册的查询执行从源头消除任意查询带来的风险面。十二、进阶实践密钥管理Secrets Management清单原文按固定周期轮换 API Key 和密钥。签名操作使用硬件安全模块HSM。在 CI/CD 流水线中实现密钥扫描secret scanning。永远不要将密钥提交到版本控制改用环境变量或密钥管理器。逐项解读定期轮换API Key、签名密钥、数据库口令都应按周期轮换缩短泄露后的可利用窗口轮换要配套旧密钥宽限期策略避免服务中断。HSM 签名对令牌签名等关键操作使用硬件安全模块让私钥物理不可导出即使应用被攻破也无法窃取签名密钥。CI/CD 密钥扫描在提交与构建阶段扫描代码库和制品及时发现误提交的密钥并触发撤销防止密钥随代码分发扩散。密钥不进版本控制密钥、令牌必须存放在环境变量或专业密钥管理器如带访问审计的 secrets 管理服务仓库中只保留引用方式绝不出现明文密钥。十三、进阶实践零信任架构Zero Trust Architecture清单原文服务间通信实现双向 TLSmTLS。即使是来自内部服务的请求也要校验。使用短生命周期令牌并自动刷新。对敏感操作实现请求签名。逐项解读mTLS 服务间认证在微服务/服务间通信中启用双向 TLS让通信双方互相验证身份与证书杜绝内网可直达的默认信任。内部请求同样校验零信任的核心是永不信任、始终校验——内部服务之间的调用同样要过认证、鉴权与审计防止攻击者横向移动后直接调用内部接口。短生命周期令牌 自动刷新短时令牌把泄露后的滥用窗口压缩到最小配合自动刷新机制在令牌到期前静默续期兼顾安全与体验。请求签名对转账、改密、删除等敏感操作附加请求签名基于私钥对请求要素签名并由服务端验签防止重放与中间人篡改。十四、把清单落到团队与 CI 流程清单本身是静态的价值在于融入流程。建议按以下三步落地评审阶段把八个核心章节作为设计评审 代码评审的必查项每个- [ ]对应一个必须在评审中给出实现证据的条目合并请求遵循仓库 CONTRIBUTING.md 中一次 PR 一件事、不自我批准、提交历史清晰的纪律。CI 阶段把CI CD章节自动化——接入测试覆盖率、SAST/DAST、依赖漏洞扫描、密钥扫描与组件静态扫描让清单条目变成流水线里的失败条件。发布与运维阶段把处理/输出/监控章节固化为网关策略安全响应头、限流、错误信息收敛、运行配置关闭 DEBUG、关闭目录列表与告警规则IDS/IPS、异常模式、敏感日志审计。此外若你的团队希望维护多语言安全文档可以参照本仓库的翻译规范fork 后翻译 README.md并以README-[语言代码].md的命名新建文件如印地语版 README-hi.md详见 CONTRIBUTING.md。十五、延伸阅读清单在也可以看看一节给出了两个方向性参考本文不展开外部链接API 开发工具资源集合面向构建 RESTful HTTP JSON API 的有用资源集合可作为实现层选型的补充资料。关于 JWT 的立场清单明确提出不一定需要 JWT直接用随机生成的 API Key 即可如果确实需要非对称加密或防篡改能力再考虑 JWT 的替代方案。这提醒我们按实际威胁模型选型而不是默认引入重量级机制。继续深入阅读本仓库英文原版README.md简体中文版README-zh.md本文所依据的印地语版README-hi.md贡献与翻译规范CONTRIBUTING.md开源许可MITLICENSE赞分享网络安全应用安全【免费下载链接】API-Security-ChecklistChecklist of the most important security countermeasures when designing, testing, and releasing your API项目地址https://gitcode.com/gh_mirrors/ap/API-Security-Checklist点击查看免费下载相关推荐探秘API安全Shieldfy的API Security Checklist深度解析探秘API安全Shieldfy的API Security Checklist深度解析 在数字化时代API应用程序接口已成为连接服务和数据的关键桥梁。然而网络安全应用安全API Security TestingAPI 安全测试指南从 OWASP API Top 10 到可落地的测试清单API Security TestingAPI 安全测试指南从 OWASP API Top 10 到可落地的测试清单 在 AG Kit 的 api pat人工智能AI 技能AI 插件如何快速掌握数据可视化金融时报Chart-doctor完整指南如何快速掌握数据可视化金融时报Chart doctor完整指南 在数据驱动的时代您是否曾为选择正确的图表类型而困惑面对复杂的数据如何将其转化为清晰易懂的上一篇如何永久保存微信聊天记录WeChatMsg完整指南下一篇Gas Town Dolt集成分布式版本控制与工作状态持久化终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考