Getting API security right
summary
A survey of ~30 e‑health apps finds 77% had hard‑coded API keys and 7% exposed credentials, and every inspected backend shows broken object‑level authorization (BOLA). Real incidents include Grindr leaking password‑reset tokens in JSON and apps enforcing limits only in the client (Bumble). Practical fixes: use DTOs to avoid excessive data exposure, centralize authorization policies for auditability, write OpenAPI contracts and use tools like Fuzz Lightyear or API firewalls (Cloudflare/42Crunch) to enforce schemas and catch mass‑assignment and token pitfalls.
AI-written summary · about
chapters (23)
- 0:00API security fundamentals
- 1:46Security in development
- 4:34OWASP API Top 10
- 5:16API failures in Bumble and Twitter
- 9:05API enforcement over client-side
- 9:26Data exposure in password reset
- 11:14JSON marshalling leaks
- 14:47Mass assignment fixes
- 16:53Testing APIs in production
- 18:17API contracts for security
- 21:08Why API contracts underused
- 22:55OpenAPI contracts importance
- 23:16Broken object authorization
- 26:46Function vs object authorization
- 29:09Auditability in policies
- 31:16Centralized authorization
- 34:49Authentication and sessions
- 37:41Web sessions vs OAuth tokens
- 41:14JWT security pitfalls
- 42:40Handling failures and compartmentalizing APIs
- 44:48API firewalls role
- 47:16Perimeter security bypass
- 47:57Steps to improve API security
