Addressing OWASP API Security Top 10 starts at design time
summary
Argues that API security must be designed, not bolted on, with concrete practices: use OpenAPI contracts or AsyncAPI to describe inputs, outputs, headers and JWT claims, run automated positive and negative tests against those contracts, and retire old versions. Calls out the top real failure as authorization with IDOR/authorization failures, notes scale like 400–500 APIs per org, recommends rate limiting per operation, embedding appsec into dev teams, and automating testing and deployment so fixes happen before production.
AI-written summary · about
chapters (18)
- 0:00Intro
- 0:37Welcome
- 1:18Problems piling up
- 3:02API Security Top 10
- 3:50Why are there still problems
- 4:48Security is still real
- 5:19Traditional security approaches
- 6:12The scale of APIs
- 7:13The call to action
- 9:43Know your API
- 11:35API contracts and definitions
- 13:23Data
- 15:23Access Control
- 17:02Positive Security Approach
- 17:50Operating
- 19:46Call to action
- 22:01Conclusion
- 22:21Where do you see the biggest space for change
related talks
35mSecuring Your API: The OWASP Top 10
17mAPI Security Simplified: Practical Tips & Tools
30mDon’t Worry, Be API: Addressing AppSec’s Newest Challenge
31mOWASP API Security Project
01h 29mAPI Vulnerabilities and What to Do About Them
51mHarmonizing the OWASP API and Application Top 10 Lists
26mOffensive API Penetration Testing
30mBOLA, IDOR, MA, BFLA. Welcome to the OWASP API Top 10!