API Security By Design
summary
Claim: fixing APIs at design time dramatically reduces exploitable issues and uncovers hundreds to thousands of problems when tested. Evidence: many public APIs show failures to constrain sequential IDs, allow unbound parameters (pagination requests for millions, SQL payloads), and expose server-side properties; internet traffic through APIs runs 60–90%+ and logic abuse accounts for ~30% of attacks. Tools and results: run Spectral, Schemathesis and Fener, generate specs with Atom or traffic tools, and automated contract tests find real mismatches at scale.
AI-written summary · about
chapters (11)
- 0:00API security by design
- 3:57Why API security matters
- 8:09Golden rule of API security
- 12:24Sequential IDs risks
- 15:58Flexible schemas risks
- 19:28Unbound parameters risks
- 25:05Server-side property exposure
- 27:11Vulnerable user flows
- 32:26Testing API security
- 36:40Resources and reading
- 37:42Q&A
related talks
31mAPI security
24mMastering API Security: From Design to Deployment
17mAPI Security Simplified: Practical Tips & Tools
27mAPI Productivity by Design
24mAPI Security in DevSecOps: Built-In, Not Bolted On
08mAPI Security Risks
16mDo the Right thing, shift Left!
24mAPI security, mitigate API abuses using machine learning