API安全性和查询过滤

1）为什么需要它

API是平台的外部和内部边界。身份验证，授权，验证或请求正常化中的任何错误都会转化为漏洞的利用（BOLA/IDOR，injection，SSRF，大规模过度运行，资源消耗）。目的：通过可测量的SLO和风险控制,创建从外围到业务规则的多层保护（深度防御）。

2） API库存和分类

API目录：所有服务/最终产品的注册表，所有者，版本，客户类型（web，mobile，合作伙伴），模式（公共/合作伙伴/内部），PII/赠与。
关键性：高级（财务交易/授权），中级（简介阅读），低级（公共手册）。
攻击面：REST, GraphQL, gRPC, WebSocket, webhooks。
状态：prod/staging/experimental, precate policy,令牌/密钥寿命。
影子/废弃的API：通过日志光盘检测，eBPF/Service Mesh遥测，与目录比较。

3）威胁模型（简述）

识别：代币劫持，会话固定，MitM，重播。
授权：BOLA/IDOR，水平/垂直升级。
输入：注入（SQL/NoSQL/LDAP）,模板/序列化,路径旅行,标题。
流量：DDoS/L7-fluds,请求缓慢,幻影后退。
集成：不安全的webhooks, SSRF通过URL设置,文件下载/扫描。
逻辑：滥用奖金，种族，不一致性。

4）基本安全标准（最低限度）

1.TLS 1.2+无处不在；HSTS;弱密码被禁用。
2.身份验证：客户OAuth2/OIDC，mTLS/或 HMAC 是服务K服务。
3.授权：集中PDP（RBAC/ABAC），对象级验证（BOLA）。
4.验证：严格模式（OpenAPI/JSON Schema/Protobuf）,多余字段故障。
5.限制：rate/quotas+burst, per 客户端/per-IP/per令牌。
6.在写作操作中具有相等性，可防止重播/赛车。
7.WAF/gateway过滤：路径/标头规范化,deny-list, payload-anti-Patters块。
8.保密：KMS/Vault，密钥轮换/证书，泄漏控制。
9.可观察性：跟踪、安全审计逻辑（谁/什么/何时/结果），异物。
10.程序：事件剧本，测试案例和常规五旬节/DAST。

5）令牌验证和管理

OAuth2/OIDC：短寿命访问令牌，严格按照OIDC改造；在门户上检查audience/issuer/exp。
JWT: RS256/ES256;最低限度的克莱姆集合；"nbf/exp/aud"是强制性的；禁止拥有PII。通过JWKS轮换密钥。
DPoP/PoP：将令牌绑定到客户端密钥,以减少重播/劫持风险。
内部系统和受信任合作伙伴的mTLS（CN/SAN认证，CRL/OCSP）。
HMAC（签名）：确定性规范化（方法+路径+timestamp+nonce+body-hash）；有效时间窗口（± 300s）。
浏览器会话：SameSite=strict/lax, HttpOnly, Secure；CSRF防护（double submit/state tokens）。
客户端存储：在移动上-安全存储（Keychain/Keystore）,防借记保护,固定证书。

6）授权（BOLA-first）

对象级别：每个操作都会检查特定资源的权限（资源所有者/scope/属性）。
RBAC/ABAC：角色+属性（国家/地区，细分市场，风险限制，KYC级别）。
策略：deny-by-default；明确的对决；政治转型；测试负面桉例。
解决方案Kesh：在角色/细分市场发生变化时，自适应TTL+残疾。

7）过滤和正常化查询（在网关/WAF）

正常化：重复大满贯收缩，禁止"……/"，一次解码，修剪空格/零字节。
标题：allow-list（"Host"，"Content-Type"，"Accept"，"Authorization"，"Date"，"Idempotency-Key"，需要跟踪标题）。
方法："GET/HEAD"不带身体；"POST/PUT/PATCH"-具有"application/json"类型或严格允许。

尺寸： max-body，max-headers，max-path；early-reject 413/431.

文件：MIME验证器,防病毒/防沙盒,禁用活动内容,重新设计/消毒图像。
URL转发/网关：SSRF单元（deny private ranges/metadata IP,只有"https", allow-list域）。
SQL/NoSQL模式：通过WAF规则集+服务器查询参数化注入签名。

标头策略示例（伪格式）

deny_headers: ["X-Forwarded-Proto","X-Original-URL","Proxy-Connection","Destination"]
require_headers: ["Authorization" (для protected), "Content-Type" (для write)]
strip_duplicates: true max_header_count: 32 max_header_size: 16KB

8）限制，配额和反机器人保护

Rate limiting: token-bucket/ leaky-bucket;级别-per IP、per API key、per user、per org。
Quotas：每日/每月，用于写作/专有方法。
适应性：异常时的动态收紧（sudden爆发/信用）。
Slow-loris/slow-POST：读取/保持活力，限制并行连接。
Antibot：设备指纹,行为特征,proof-of-work/kapcha风险增加,tor/代理网络列表。
IP控制：地理/ASN过滤器，"肮脏"子网的deny表，合作伙伴/管理面板的allow表。

9）输入和电路验证

失败关闭：任何未通过方案的都是400。多余的字段是偏转。
类型/范围：数字，日期（UTC/ISO-8601），enum值，行长度，regexp。
JSON质量：最大测试，大阵列/密钥禁令，canonical order（可选）。
商业验证："Idempotency-Key"的幂等；反限制规则（操作频率限制,amount caps）。
GraphQL：深度/复杂性限制，allow-listed queries，per字段授权。
gRPC：严格的Protobuf方案，强制字段，消息大小限制。

10）Webhooks和外部呼叫

标题：HMAC具有timestamp/nonce；在处理前进行验证；窗口+/-5分钟。
交付：带有指数暂停和抖动的转发；最大尝试；事件ID重复数据消除。
供应商的IP allow-list；单独的子域/路径；最小托管堆栈。
答案：仅在成功进行内部录制后才进行2xx；否则4xx/5xx具有清晰的代码。
传出SSRF控制：在呼叫后,URL为allow-list,禁止私有地址。

11）加密和秘密管理

在频道：TLS 1。2+/1.3、固定,严格的密码政策。
静止：DB/对象存储加密，PII/findans的单独密钥。
KMS/Vault：中央机密存储、短TTL、自动旋转。
密钥和证书：随行人员；签发审计；禁止推断到日志中。
令牌输入：离线召回列表（revocation），简称"exp"。

12）可观察性、审计和响应

安全性日志：身份验证尝试/成功,授权失败,rate-limit事件,角色/限制更改。
跟踪：correlation-ID端到端；跟踪外部呼叫。
度量标准：RPS，P95/P99 latency，代码错误率，401/403/429比例，限额命中率，异常。
Alerts：401/403/429激增，5xx生长，频繁的idempotency冲突，图QL复杂性的急剧偏差。
Playbooks：锁定密钥/令牌,快速回滚规则,加热deny清单,通知服务所有者。
Forenzika：保留有争议的薪水（安全编辑PII）,在孤立的看台上重新播放。

13）错误和客户响应

单一错误格式（代码、消息、trace-id、类别）。
无泄漏：不披露SQL、表名、内部aidi；403而不是"为什么不是"。
代码：400（验证）、401（无认证）、403（无权）、404（伪装存在）、405/406、413/429、500/503。
Retry-Hints: для 429 — `Retry-After`;相似性-重复使用相同键的建议。

14）建筑模式

零信任：mTLS，所有服务之间的明确授权，最低特权。
API网关+WAF+服务-mesh：职责分工-周边，L7策略，内部身份验证。
Canary/Blue-Green：分阶段推出新的过滤规则，并进行监控。
失效：对于关键写作,拒绝比允许不正确的操作更好。
Backpressure：队列/缓冲区,电路断路器,timeouts/budgets。

15）实用规则的示例（伪伪）

15.1限制路径和方法

/api/v1/payments:
allow_methods: [POST, GET]
auth: oauth2_required body:
content_type: application/json max_size: 256KB

15.2相似性

require_header: Idempotency-Key (UUIDv4)
store: redis:ttl=24h on_duplicate: return_previous_result

15.3请求签名（HMAC）

signature:
scheme: "HMAC-SHA256"
required_headers: ["X-Signature","X-Timestamp","X-Nonce"]
allowed_drift: 300s string_to_sign: METHOD + "\n" + PATH + "\n" + SHA256(body) + "\n" + X-Timestamp + "\n" + X-Nonce

15.4个SSRF保护

outbound_http:
allowlist_domains: ["kyc. partner. com","psp. example. net"]
block_private_ip: true require_https: true

15.5 GraphQL限制

graphql:
max_depth: 8 max_complexity: 500 allowlisted_operations_only: true

16） iGaming/财务细节

细分限制：取决于CUS/国家/风险概况。
时间窗口：存款/收款频率规则，交易之间"冷却"。
反抽奖：对帐户/设备/IP/支付工具的一致性锁定。
审核监管机构的要求：存储操作和决策逻辑（KYC/AML）、恢复期、不变日志。

17）prod就绪清单

• 完整的API目录和数据流映射（PII/财务已标记）。
• OpenAPI/Protobuf电路，验证测试和CI中的合同。
• mTLS/HMAC/OAuth2定制；短的TTL令牌；按键旋转。
• BOLA测试和负面授权桉例；集中式PDP。
• 限额/配额/防波特，防御慢速下滑；IP过滤器。
• WAF/正常化门户规则，反注射签名。
• 写作操作的幂等性；复制保护。
• Webhook 签名和allow-list；孤立的endpoints。
• KMS/Vault中的秘密；加密的storajs；异常。
• Dashbords，Alerta，审核日志；工作剧本事件。
• 定期五旬节/DAST/SAST，漏洞跟踪和丢弃补丁。

18）反模式（不可能）

信任"X-Forwarded-"，而周边没有TLS硬端。
采用任意的"内容类型"和"软"JSON方案。
长寿的JWT，没有召回/旋转。
在代码中溷合角色和业务规则,而无需集中化策略。
带秘密/PII的逻辑；向外详细的500条消息。
"临时"开放的终点，没有限制和授权。

19）翻新和拆除

路径/标题中的版本；支持政策（如N-2）。
公告：清除时间表,监视旧版本的使用,管理禁用。
兼容性：客户/合作伙伴合同和测试矩阵。

20）安全测试

合同模式测试/策略,fuzzing输入,negative auth。
具有限制/配额的穿孔配置文件，保护测试（混沌流量）。
Red-team/bug-bounty： BOLA脚本、SSRF、签名/中继、GraphQL复杂性。

TL;DR

1.API目录+严格的架构。
2.客户OAuth2/OIDC，内部的mTLS/HMAC。
3.每个资源的BOLA周边（ABAC/RBAC）。
4.过滤：路径/标头标准化,限制,WAF规则。
5.等效性，签名，复制/SSRF保护。
6.KMS/Vault和秘密轮换。
7.可观察性，异同，剧本。