网络安全应用安全【免费下载链接】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.md展开系统讲解在设计、测试、发布 API 三个阶段必须核对的安全对策从身份认证、访问控制、OAuth 授权、输入/输出防护到 CI/CD 流水线与运行时监控并覆盖速率限制、GraphQL 安全、机密管理与零信任等进阶实践。读完本文你将得到一张可直接逐项勾选、可用于安全评审与开发自检的完整清单并理解每一项背后的攻击原理与落地要点。一、清单概览一张贯穿 API 全生命周期的安全核对表API-Security-Checklist 是一份纯文档驱动的安全清单项目它不像传统框架那样提供可运行的代码而是把「设计、测试、发布 API」时最重要、最容易被忽略的安全措施整理成可勾选的- [ ]条目。仓库以 README.md 为唯一权威版本并维护了大量语言翻译简体中文 README-zh.md、繁体中文 README-tw.md、日文、韩文、法文等便于不同地区团队直接对照使用。清单主体分为 8 大维度另有 4 组进阶实践维度覆盖的核心问题对应章节身份认证Authentication如何确认「你是谁」第二节访问Access如何控制「谁能进来」第三节授权Authorization / OAuth如何约束「你能做什么」第四节输入Input如何防御「恶意数据进来」第五节处理Processing如何安全地执行业务逻辑第六节输出Output如何安全地把数据给出去第七节CI CD如何在发布流程中守住安全底线第八节监控Monitoring如何发现「正在发生的攻击」第九节使用方式很简单把清单当作评审工具开发前对照设计、测试时对照实现、发布前对照部署逐项勾选并补充实现证据。下文将逐条讲解每一项「为什么重要」以及「如何落地」并补充中文版清单中额外的本土化检查项。二、身份认证Authentication把「你是谁」交给标准协议身份认证是 API 安全的第一道门。README.md 的身份认证小节给出了 4 条硬性要求README-zh.md 又补充了 3 条贴近前端与框架实践的建议不要使用Basic Auth改用标准认证协议。Basic Auth 将用户名密码以 Base64 形式随每次请求传输既无过期机制也难以撤销应优先采用 OAuth 2.0、OpenID ConnectOIDC或 SAML 等成熟标准。不要在Authentication、token 生成、密码存储上重新发明轮子。会话管理、令牌签名、密码哈希都是高风险的密码学与安全工程问题务必使用经过审计的标准库密码哈希优先选择bcrypt、scrypt或argon2令牌生成使用库内置的随机源而不是手写md5(rand())之类的拼凑方案。登录启用Max Retry最大重试次数与封禁jail功能。限制单位时间内密码错误次数超出后临时冻结账号或 IP可显著抬高暴力破解的成本。中文版进一步建议密码或账号登录失败时返回模糊的提示信息避免暴露「用户名不存在」或「密码错误」这类可被攻击者利用的枚举线索。加密所有敏感数据。无论存储在数据库、缓存还是消息队列中敏感字段都应采用强加密如 AES-256保护。不要将 API Key、云组件 Key 等硬编码到前端页面或 APP 中。前端资源可被任何人抓取硬编码等于公开凭据密钥应只存在于服务端环境。使用开源框架时禁止使用默认 Key如 Shiro。默认密钥是公开知识攻击者可直接利用其构造认证绕过上线前必须替换。从仓库结构看这些条目在 README.md 与 README-zh.md 中一一对应属于清单作者明确推荐的安全基线而非特定框架的定制要求适用于任何语言与技术栈的 API 项目。三、访问Access控制流量、加密传输、收敛暴露面访问维度的核心是「不让该进来的人进来不让人看到不该看的东西」限制请求量Throttling以避免 DDoS / 暴力攻击。对单 IP、单账号的请求频率设上限避免攻击者用海量请求耗尽资源。中文版补充对 API 接口访问进行速率限制防止业务数据被批量爬取——爬虫往往与攻击共享同一套流量特征。服务端使用 HTTPSTLS 1.2 与安全加密套件防止中间人攻击MITM并确保Host头与 SNIServer Name Indication一致。TLS 1.2 以下协议与RC4、3DES、CBC等弱套件应显式禁用避免降级攻击。使用HSTSHTTP Strict Transport Security头配合 SSL防止 SSL Strip 攻击。落地示例Strict-Transport-Security: max-age31536000; includeSubDomains让浏览器强制走 HTTPS 并拒绝明文回退。关闭目录列表。Web 服务器如 Nginx 的autoindex、Apache 的Options Indexes默认可能暴露静态目录内容中文版进一步要求禁止公开存储文件列表的可未授权访问。私有 API 仅允许白名单 IP / 主机访问。中文版还强调三类「暴露面收敛」禁止将内部组件接口、登录管理接口暴露于公网禁止将 SourceMap 文件暴露到公网否则等于把源码交给攻击者禁止将 API 接口描述文档暴露到公网降低攻击者侦察收益。这类「默认关闭、按需开放」的思路正是清单反复强调的原则能不外露的入口一律不外露。四、授权OAuth 的四条保命条款OAuth 是整个授权体系中最容易出错的协议之一清单针对其最常见漏洞给出了 4 条硬规则README.md 中「Authorization OAuth」小节始终在服务端验证redirect_uri只允许白名单 URL。redirect_uri是授权码回跳地址若未校验攻击者可构造恶意 URI 窃取授权码此即经典的「开放重定向 授权码劫持」攻击链。始终用授权码code交换令牌而不是直接返回令牌禁止response_typetoken。隐式授权Implicit Flow把 access_token 直接暴露在浏览器 URL 与历史记录中风险远高于授权码模式应使用 Authorization Code Flow并配合 PKCE 应对原生客户端场景。使用state参数并填充随机哈希防止授权流程中的 CSRF。state将用户发起的授权请求与回调绑定攻击者伪造的回调因无法预测随机值而被拒绝。为每个应用定义默认 scope并校验 scope 参数。防止应用越权申请、或被诱导获得超出预期的权限范围。从 README-zh.md 的对应翻译看这四条被完整保留说明它们是清单作者认定的 OAuth 最小安全集任何自研或第三方 OAuth 实现都应对照核查。五、输入Input在数据进入业务逻辑前设防输入维度处理的是「请求到达代码之前」的安全共 7 条使用与操作相符的 HTTP 方法GET读取、POST创建、PUT/PATCH替换/更新、DELETE删除如果请求的方法不适用于目标资源返回405 Method Not Allowed。语义化路由不仅能避免缓存与幂等性问题也让安全规则如对写操作强制校验有清晰的挂载点。校验请求头Accept中的content-type内容协商只允许你支持的格式如application/xml、application/json不匹配时返回406 Not Acceptable。校验 POST 数据声明的content-type与实际编码一致如application/x-www-form-urlencoded、multipart/form-data、application/json。声东击西的编码声明常被用来绕过解析差异。校验用户输入避免常见漏洞XSS、SQL 注入、远程代码执行RCE等。原则是「永远不信任输入」使用参数化查询/预编译语句防 SQLi输出编码防 XSS对文件路径、命令参数等使用白名单校验。不要在 URL 中携带任何敏感数据credentials、Passwords、security tokens、API keys改用标准的Authorization请求头。URL 会进入访问日志、浏览器历史、Referer 头与 CDN 缓存等于把凭据散播到了多个地方。仅使用服务器端加密。客户端加密前端可被篡改无法作为信任边界加密与解密必须发生在服务端。使用 API Gateway 服务启用缓存、速率限制策略如Quota、Spike Arrest、Concurrent Rate Limit并动态部署 API 资源。网关把限流、鉴权、缓存从业务代码中剥离出来作为统一安全前置层Quota配额、Spike Arrest突发压制、Concurrent Rate Limit并发上限分别对应三类典型滥用形态。六、处理Processing业务逻辑中的安全红线请求通过输入校验后进入处理阶段这一环节的漏洞往往更隐蔽检查所有端点是否都处于认证保护之后避免「被破坏的认证体系」broken authentication。最常见的错误是新增接口忘了加中间件、或某些端点绕过了统一的认证过滤器。避免暴露用户专属资源 ID用/me/orders而非/user/654321/orders。前者从会话推断身份从根上消除了 IDOR 类越权的可能性中文版进一步强调对访问的资源进行权限检查防止横向越权——即便使用/me风格也仍需对每个资源做属主校验。使用UUID代替自增 ID。自增 ID 不仅泄露业务规模注册量、订单量也为遍历攻击提供了天然的下标。解析 XML 时确保实体解析entity parsing关闭避免XXEXML 外部实体攻击。XXE 可读取服务器本地文件、发起 SSRF 甚至执行远程文件包含。各语言的防御手段包括PHP 使用libxml_disable_entity_loader(true)Java 设置XMLConstants.FEATURE_SECURE_PROCESSING并禁止外部 DTDPython 使用defusedxml替代标准库解析器。解析 XML、YAML 等带锚点与引用anchors and refs的语言时确保实体扩展entity expansion关闭避免Billion Laughs / XML bomb。这类「指数实体扩展攻击」通过层层嵌套的实体引用把几 KB 的请求膨胀成数 GB 的内存占用。缓解手段包括禁用嵌套实体、限制 DTD 大小与解析深度。文件上传使用 CDN。上传内容交由 CDN 承载与分发避免业务服务器直接对外提供不可信文件的执行环境如图片木马、SVG 中的脚本。处理海量数据时使用 Workers 与 Queues 尽可能在后台处理快速返回响应避免 HTTP 阻塞。把耗时任务异步化既改善用户体验也避免长连接被攻击者用作资源消耗武器。不要忘记关闭 DEBUG 模式。调试模式会输出堆栈、SQL、环境变量等敏感信息是生产环境的高危泄露源。在可用时使用不可执行堆栈non-executable stacks。启用 NXNo-eXecute/ DEP 位、对部署目录执行noexec挂载可在系统层面压缩缓冲区溢出类攻击的利用空间。中文版补充一条与动态语言相关的典型坑禁止使用类似 PHPextract的函数将接口输入参数直接转换为变量——这等于把攻击者的输入变成代码执行环境里的变量极易引发变量覆盖与逻辑绕过。七、输出Output让响应不泄露、不误传、不误导输出阶段是「数据离开服务端」的最后一关清单给出了 8 条发送X-Content-Type-Options: nosniff头禁止浏览器对响应内容做 MIME 嗅探防止「内容类型混淆」类攻击如把 JSON 当 HTML 渲染引发 XSS。发送X-Frame-Options: deny头禁止页面被 iframe 嵌入阻断点击劫持Clickjacking。发送Content-Security-Policy: default-src none头默认禁止加载一切外部资源把 XSS 的利用面压到最小。删除指纹头X-Powered-By、Server、X-AspNet-Version等。它们向攻击者免费提供技术栈与版本信息便于其定向寻找已知漏洞。强制响应content-type如果返回的是 JSONcontent-type就必须是application/json避免「JSONP/HTML 混淆」这类因类型声明不符导致的攻击。不要向客户端返回过于具体的错误信息可能泄露实现细节改用通用消息详细错误只记录在服务端日志。中文版补充返回统一的错误页面不要把调用堆栈等信息展示在错误页面中。不要返回敏感数据如credentials、Passwords、security tokens。中文版的两条细化要求值得注意仅返回前端需要的业务数据禁止返回过多类型敏感数据最小化数据暴露敏感业务数据在后端脱敏后返回禁止在前端对数据进行脱敏——脱敏逻辑放在后端才具备可信性与一致性。根据操作结果返回恰当的状态码200 OK、400 Bad Request、401 Unauthorized、405 Method Not Allowed等。状态码是客户端感知 API 语义的通道用错状态码如用 200 表示一切结果会破坏错误处理链路也为自动化扫描提供错误信号。八、CI CD把安全检查内建到发布流水线清单将安全从「上线后补救」前移到「发布前拦截」共 6 条用单元测试与集成测试的覆盖率审计设计与实现。测试不仅是功能保障也是安全行为鉴权、限流、校验回归的载体。引入代码审查流程禁止自我批准合并。多一双眼睛就能多拦截一类逻辑漏洞与「走后门」代码。推送到生产环境前确保服务的所有组件包括第三方库与其它依赖都被杀毒软件静态扫描过。供应链里的恶意代码与已知病毒必须在发布前被识别。持续运行安全测试静态分析SAST与动态分析DAST。SAST 扫描源码缺陷DAST 对运行中的接口发起自动化攻击探测两者应纳入流水线而非一次性动作。检查依赖软件与操作系统是否存在已知漏洞。借助 CVE 数据库与依赖扫描工具在漏洞被公开利用前完成升级或规避。为部署设计回滚方案。安全事故或错误配置一旦上线可快速回退到上一个已知良好版本缩短暴露窗口。九、监控Monitoring攻击发生后如何「看见」再好的防护也无法保证零突破监控维度的目标是让异常可见、可告警、可追溯对所有服务和组件使用集中式日志。分散的日志无法还原攻击链路集中收集如 ELK/Kibana是审计与溯源的前提。使用代理agent监控所有流量、错误、请求与响应。全量观测而非抽样才能捕捉到低频但高风险的异常。配置多渠道告警SMS、Slack、Email、Telegram、Kibana、Cloudwatch 等。告警应绑定明确的阈值与责任人确保「监控到」能转化为「处置到」。确保没有记录任何敏感数据信用卡号、密码、PIN 等一律不得进入日志。日志泄露是数据泄露的高发途径应通过字段过滤、脱敏与日志分级来控制。使用 IDS 和/或 IPS 系统监控 API 请求与实例。入侵检测IDS发现可疑行为入侵防御IPS进一步阻断中文版还补充了使用 API 检测设备进行 API 资产梳理与日志审计即对内部 API 资产做持续盘点防止「影子 API」脱离安全管控。十、进阶实践面向高威胁场景的 4 组安全对策README.md 在清单主体之外以「API Security Best Practices (Advanced)」名义给出了 4 组进阶对策面向更高威胁模型与更成熟的工程团队10.1 速率限制与滥用防护Rate Limiting Abuse Prevention按 API Key 与 IP 分别实现滑动窗口限流sliding window rate limiting。滑动窗口比固定窗口更平滑能同时避免「窗口边界突发」与「单账号集中滥用」。对重复失败的身份认证尝试使用指数退避exponential backoff。失败次数越多下次重试间隔越长成倍抬高暴力破解成本。可疑活动后引入 CAPTCHA 或工作量证明proof-of-work挑战。用机器成本对抗自动化把攻击者从「零成本刷接口」变为「高成本消耗战」。监控并告警异常的 API 使用模式时间、流量、端点维度。突然的深夜高流量、对单个端点的集中访问往往早于正式攻击出现。10.2 GraphQL 专属安全GraphQL-Specific Security生产环境禁用 introspection内省查询。GraphQL 的 introspection 会把完整 schema 暴露给任何人等于公开了全部数据模型生产环境必须关闭。实现查询深度限制query depth limiting防止嵌套查询攻击——攻击者用一层套一层的嵌套字段构造指数级查询成本。使用查询成本分析query cost analysis按字段权重估算查询开销防止资源耗尽resource exhaustion。生产环境尽可能使用查询白名单persisted queries / whitelist只允许预先注册的查询被执行。10.3 机密管理Secrets Management定期轮换 API Key 与密钥。轮换周期应短于密钥可能泄露的窗口期且轮换流程新旧并行、自动切换要可自动化。签名操作使用硬件安全模块HSM。私钥不出硬件边界从物理层杜绝密钥窃取。在 CI/CD 流水线中实施密钥扫描secret scanning在提交或构建阶段自动拦截硬编码的密钥。绝不把机密提交到版本控制——使用环境变量或密钥管理服务secret managers。这条与第五节「不要在 URL 中携带敏感数据」互为表里凭据只出现在受控的位置。10.4 零信任架构Zero Trust Architecture服务间通信实施双向 TLSmTLS。服务与服务的每一次调用都互相验证证书而非默认信任内网。即使是来自内部服务的请求也全部校验。零信任的核心假设是「网络不可信」内网不再是信任边界。使用短生命周期令牌并支持自动刷新。令牌过期时间越短泄露后的有效窗口越小。对敏感操作实施请求签名request signing。防篡改 防抵赖确保请求内容在传输与处理间未被修改。这 4 组进阶项与前面的基础清单是互补关系基础清单守住底线进阶实践应对高价值 API 的高强度攻击面。项目维护者显然有意让清单覆盖「入门团队按图索骥」与「成熟团队纵深防御」两层需求。十一、多语言版本、延伸阅读与参与贡献仓库为清单维护了大量官方翻译覆盖东亚、东南亚、欧洲、中东等主要语言市场。团队可以直接使用母语版本做评审与培训例如简体中文README-zh.md繁体中文README-tw.md日文README-ja.md、韩文README-ko.md、法文README-fr.md、德文README-de.md 等完整语言列表见 README.md 开头的语言导航行在「See also」延伸阅读中清单作者给出了两个外部参考方向其一是面向构建 RESTful HTTPJSON API 的实用工具资源集合yosriady/api-development-tools其二是关于「你可能并不需要 JWT——使用随机生成的 API Key 往往已足够只有在确实需要非对称加密或防篡改时才考虑 JWT 替代方案」的观点文章。这两条属于作者的外部推荐具体链接与内容以 README.md 为准。如果你希望参与维护仓库的 CONTRIBUTING.md 说明了协作方式通过 fork 仓库、提交 Pull Request 贡献新增翻译时把翻译后的 README 按README-[语言代码].md命名如德语为README-de.md并保持单一 PR 只做一件事、提交历史清晰。仓库采用 MIT 许可证见 LICENSE这意味着清单可以自由用于内部安全评审、文档化与再分发。项目联系邮箱为teamshieldfy.io见 README.md 末尾的贡献说明。结语把清单变成团队的「安全契约」API-Security-Checklist 的价值不在于条目数量而在于它把分散在各类漏洞文档里的经验压缩成了一张可执行、可勾选、可评审的检查表。建议的落地路径是设计阶段对照「身份认证 / 授权 / 输入」三节测试阶段对照「处理 / 输出」两节并补齐 CICD 检查上线前后对照「访问 / 监控」两节做暴露面收敛与观测告警有 GraphQL、高吞吐或强合规诉求的团队再逐条对照第十节的 4 组进阶实践。每勾选一项都应写下对应的实现位置与测试证据——安全不是一次评审而是持续内建的过程。赞分享网络安全应用安全【免费下载链接】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 插件解析 backend-api-security 插件的后端架构师 Agent一份可落地的分布式 API 设计智能体清单解析 backend api security 插件的后端架构师 Agent一份可落地的分布式 API 设计智能体清单 本文以仓库 backend api sAI 插件AI 技能开发工具上一篇swift-create-xcframework错误排查指南常见问题与解决方案大全下一篇CookieCutter嵌套模板复杂项目结构设计的终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考