dheeraj-jayaswal/API-From-The-Trenches

## 🎯 本系列的内容 这不是一篇关于什么是 API 的入门指南。这是一份经过实战检验的企业级参考文档，记录了我在受监管和高风险企业领域的实际评估中，是如何进行 API 安全测试的。 本系列的每一篇 write-up 都反映了我在企业生产环境中确认过的攻击模式。每个报告模板都反映了我在实际评估中使用的工具命令。 **本系列填补的空白：** 大多数 API 安全资源只涵盖理论。本系列涵盖了实践——特别是在企业环境中的实践，在这些环境中，风险涉及法规合规性、合同规定的数据保护义务以及大规模的真实用户数据。 ## 🧭 这与我的其他 Repos 的关系 | Repo | 用途 | |---|---| | **API-From-The-Trenches** *(当前 repo)* | 深入的技术 API 安全参考——完整的方法论、OWASP API Top 10 映射、工具工作流、标志性发现 | | [From-Dev-To-Attacker](https://github.com/dheeraj-jayaswal/From-Dev-To-Attacker) 的 `api-security/` 文件夹 | 从开发者的视角出发的较短篇幅的“为什么存在此漏洞”的配套文章，带有企业领域影响框架——建议先阅读这些以建立直觉，然后再回到这里深入了解 | | [Bug-Bounty-Hunting-Companion](https://github.com/dheeraj-jayaswal/Bug-Bounty-Hunting-Companion) | 将真实的已披露 HackerOne 报告转化为可复现的检查清单 | | [AppSec-From-The-Trenches](https://github.com/dheeraj-jayaswal/AppSec-From-The-Trenches) | 超越 API 范畴的更广泛的企业 AppSec 知识库 | ## 🧠 为什么 API 安全是真正容易出成果的地方 ``` The shift to API-first architecture has fundamentally changed the attack surface. Traditional web app (2010-2015): Browser → HTML form → Server → HTML response Attack surface: visible form fields, URL parameters Modern enterprise application (2020-present): React/Angular SPA → REST/GraphQL API → Microservices → Databases Attack surface: JSON bodies, auth tokens, HTTP methods, API versioning, inter-service trust, mass assignment The developer assumption that breaks enterprise APIs: "Only our frontend calls these endpoints" → Wrong. Any HTTP client with a valid token can call them. → The API must enforce access control itself. → The UI filtering is not a security control. What this means for enterprise testing: → BOLA/IDOR is the most common Critical finding (not SQLi) → Mass assignment via undocumented fields is frequently missed → Old API versions are consistently less secure than current ones → Mobile API backends have weaker controls than web backends → GraphQL introspection hands attackers the complete data model ``` ## 📚 系列内容 ### 🔷 基础 | # | 主题 | 文件 | 关键企业发现 | |---|---|---|---| | 01 | REST API 安全 | [Rest-API.md](Rest-API.md) | 跨所有 HTTP 方法的 BOLA、NoSQL injection、通过 error codes 导致的 schema 泄露 | | 02 | API 认证方式 | [AUTH-Methods.md](AUTH-Methods.md) | JWT 弱 secret 破解、OAuth state bypass、RS256→HS256 混淆 | | 03 | GraphQL 安全 | [GraphQL.md](GraphQL.md) | 未经身份验证的 introspection、通过 batching 绕过 rate limit、字段级 BOLA | | 04 | API 侦察 | [API-RECON.md](API-RECON.md) | Source map RCE 链、旧 API 版本 auth bypass、JS 中硬编码的 secrets | | 05 | 用于 API 测试的 Postman | [POSTMAN.md](POSTMAN.md) | 自动化 BOLA 扫描、动态 token 刷新、Newman pipeline 集成 | ### 🔷 OWASP API Top 10 与访问控制 | # | 主题 | 文件 | |---|---|---| | 06 | Broken Object Level Authorization | [Broken-Object-Level-Authorization.md](Broken-Object-Level-Authorization.md) | | 07 | Broken Authentication | [API-Broken-Authentication.md](API-Broken-Authentication.md) | | 08 | Mass Assignment | [Mass-Assignment.md](Mass-Assignment.md) | | 09 | Rate Limiting | [API-Rate-Limiting.md](API-Rate-Limiting.md) | | 10 | Broken Function Level Authorization | [Broken-Function-Level-Authorization.md](Broken-Function-Level-Authorization.md) | | 11 | 通过 API Mutations 触发的 SSRF | [API-SSRF.md](API-SSRF.md) | | 12 | API 版本控制安全 | [API-Versioning-Security.md](API-Versioning-Security.md) | | 13 | OpenAPI / Swagger 安全 | [OpenAPI-Swagger-Security.md](OpenAPI-Swagger-Security.md) | | 14 | API7–API10 覆盖范围 | [API-OWASP-7-to-10.md](API-OWASP-7-to-10.md) | ### 🔷 工具 | # | 主题 | 文件 | |---|---|---| | 15 | 用于 API 测试的 Burp Suite Pro | [Burp-Suite-Pro-for-API-Security-Testing.md](Burp-Suite-Pro-for-API-Security-Testing.md) | ## 🏆 OWASP API 安全 Top 10 覆盖范围 | OWASP API 风险 | Write-up 覆盖范围 | 企业环境严重程度 | |---|---|---| | API1 — Broken Object Level Authorization | REST API、GraphQL | 严重 | | API2 — Broken Authentication | 认证方式 | 严重 | | API3 — Broken Object Property Level Auth | REST API (Mass Assignment) | 高–严重 | | API4 — Unrestricted Resource Consumption | REST API (Rate Limiting)、GraphQL (Batching) | 中–高 | | API5 — Broken Function Level Authorization | REST API、GraphQL | 严重 | | API6 — Unrestricted Access to Sensitive Flows | REST API (业务逻辑) | 高 | | API7 — Server Side Request Forgery | GraphQL (Mutations) | 严重 | | API8 — Security Misconfiguration | API 侦察、GraphQL | 高–严重 | | API9 — Improper Inventory Management | API 侦察 (版本枚举) | 高 | | API10 — Unsafe Consumption of APIs | 认证方式 (OAuth) | 高 | ## 🔑 我最具影响力的企业 API 发现（模式） ``` 1. BOLA on all HTTP methods — not just GET Developers protect GET endpoints for IDOR. PUT and DELETE on the same resource often have no check. One IDOR finding becomes three Critical findings. 2. JWT HS256 weak secrets Early Spring Boot tutorials used "secret" as the example signing key. Production apps were built from those tutorials. Hashcat + rockyou.txt cracks them in seconds. 3. Excessive data exposure — the DTO gap Backend returns the full database object. Frontend displays 4 fields. The API response contains 47 fields including password_hash and salary. No attack required — just Burp Suite and careful observation. 4. Old API version missing auth checks /api/v2/users/1042 → correctly returns 403 (ownership enforced) /api/v1/users/1042 → returns 200 with full data (old version, no check) "Deprecated" does not mean "disabled." 5. GraphQL introspection in production One query hands the attacker the complete data model. Type names like "AdminConfig" and "EmployeePayroll" are the roadmap. Disable it unconditionally in production. 6. Mass assignment at registration Teams add protection to profile update endpoints. They forget the registration endpoint. POST /register with role=admin — accepted more often than it should be. ``` ## 🛠️ 本系列使用的工具 | 工具 | 主要作用 | 覆盖范围 | |---|---|---| | **Burp Suite Pro** | 核心手动测试、请求篡改 | 所有 write-ups | | **Postman** | 结构化 collection 测试、CI/CD 集成 | Postman 指南 | | **ffuf** | API endpoint 和参数 fuzzing | 侦察 | | **Nuclei** | 自动化 CVE 和错误配置扫描 | 侦察阶段 | | **cURL** | 快速 PoC 验证、报告证据 | 所有 write-ups | | **jwt.io** | JWT 检查和解码 | 认证方式 | | **Hashcat** | JWT secret 破解 (-m 16500) | 认证方式 | | **InQL (Burp)** | GraphQL schema 可视化和测试生成 | GraphQL | | **Autorize (Burp)** | 自动化 BOLA/IDOR 检测 | BOLA | ## 📐 我的 API 测试方法论 — 6 个阶段 ``` Phase 1: DOCUMENTATION DISCOVERY (30 minutes) → Find Swagger/OpenAPI spec → import to Postman → Check for GraphQL introspection → Extract API endpoints from JavaScript bundles → Enumerate API versions (v1, v2, beta, internal) Phase 2: AUTHENTICATION ANALYSIS (30 minutes) → Identify auth mechanism (JWT, API key, cookie, OAuth) → JWT: decode, check algorithm, test weak secret → Test unauthenticated access to all discovered endpoints → Test token replay after logout Phase 3: BOLA / IDOR SWEEP (1-2 hours) → Create two test accounts → Configure Autorize with victim's token → Test all HTTP methods (GET, PUT, DELETE, PATCH) with victim IDs → Test IDOR in URL path, query string, body, custom headers Phase 4: DATA EXPOSURE AUDIT (30 minutes) → Compare UI rendering vs raw API response body → Document all fields present but not displayed → Test export/bulk endpoints for excessive data Phase 5: INJECTION & BUSINESS LOGIC (1-2 hours) → SQLi in all string parameters → NoSQL injection in JSON body → Rate limiting on auth and OTP endpoints → Mass assignment at registration and profile update Phase 6: DOCUMENTATION & REPORTING → CVSS score every finding → cURL reproduction command for every PoC → Secure code fix in application's language → Postman collection delivered to dev team ``` ## 🏢 企业环境 vs Bug Bounty — 关键区别 ``` Bug bounty: Find one bug → report → collect reward Enterprise testing: Systematic coverage of agreed scope → professional report → remediation support What enterprise API testing adds: ✓ Scope document review before touching a single endpoint ✓ Rate limiting awareness (shared/production environments) ✓ SOC notification when active scanning begins ✓ Evidence collection standards (every finding needs reproducible PoC) ✓ CVSS scoring and business impact statements ✓ Secure code fixes in the application's language ✓ Postman collection delivered as remediation aid ✓ Retest after fixes (closing the loop) ``` ## 🎓 我的专业背景 **IT 行业 15 年以上 | 攻击性安全 5 年以上 | Infosys Limited** 我最初是一名全栈开发人员——ASP.NET、SQL Server、JavaScript。那段开发背景是我在 API 安全测试中最大的优势。我了解为什么 API 会这样构建，了解在进度压力下会采取哪些捷径，以及当团队快速迭代时，访问控制检查会在哪些地方被遗漏。 **领域经验：** 所得税 · 银行 · 零售 · 电子商务 · 货运物流 · 教育 **认证：** - CEH — EC-Council (2021) - AWS Certified Solutions Architect – Associate (2022) - AWS Certified Cloud Practitioner (2022) - OSCP — OffSec（进行中 2025-2026） - IIT Kanpur 网络安全高管证书（进行中 2025-2026） ## 📄 许可证 [](LICENSE.md) [](https://github.com/dheeraj-jayaswal/API-From-The-Trenches/commits/main) ## 🔗 联系方式 [LinkedIn](https://linkedin.com/in/dheerajkumarjayaswal) · [Email](mailto:jaiswal.dheeraj123@gmail.com) *欢迎咨询、合作和安全方面的讨论。* ## 🔗 参考资料 - [OWASP API 安全 Top 10](https://owasp.org/www-project-api-security/) - [PortSwigger Web 安全学院 — API 测试](https://portswigger.net/web-security/api-testing) - [OWASP Web 安全测试指南 — API 测试](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-API_Testing/) - [OWASP GraphQL 安全备忘单](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html) - [JWT 安全最佳实践](https://curity.io/resources/learn/jwt-best-practices/) - [OAuth 2.0 安全当前最佳实践](https://datatracker.ietf.org/doc/html/rfc9700)

标签：API安全, CISA项目, JSON输出, OWASP API Top 10, 安全测试, 攻击性安全, 数据展示, 红队