APIs are the surface area of modern systems. Every mobile app, every SaaS integration, every microservice talks to APIs. They are also the most common breach vector reported in 2024-2025. The OWASP API Security Top 10 (2023 edition) is the canonical taxonomy of what goes wrong. This module walks through each item with concrete examples and remediation patterns — the foundation of the API Security Deep track.
Why APIs are different from web apps
- No browser context — the client could be anything, so client-side controls are zero defense
- High request rates expected — rate limiting is harder than web apps
- Object-oriented data exchange — direct exposure of internal models
- Versioning hell — old versions linger; vulnerabilities don’t get patched in deprecated paths
- Documentation as attack map — OpenAPI specs are gifts to attackers if exposed
OWASP API Security Top 10 (2023)
API1: Broken Object Level Authorization (BOLA)
The IDOR of APIs. GET /api/orders/12345 returns order 12345 even if it belongs to a different user. Most common API vulnerability by orders of magnitude. Remediation: every object access must verify the requesting user owns or has rights to the object — not just at the route layer but at the object layer.
API2: Broken Authentication
Weak token generation, missing token validation, JWT signature bypass via “none” algorithm, predictable session identifiers. Remediation: standardise on a vetted auth library; never roll your own JWT verifier; use refresh-token rotation.
API3: Broken Object Property Level Authorization (BOPLA)
Two flavours:
- Mass Assignment: client sends extra fields the API blindly accepts (
{"role":"admin"}in a profile update) - Excessive Data Exposure: API returns the entire object including fields the UI doesn’t display (password hashes, internal flags)
Remediation: explicit allow-listing of fields on input AND output, both directions.
API4: Unrestricted Resource Consumption
API allows queries that hammer your backend — unbounded list endpoints, expensive aggregations, file uploads with no size limits. Remediation: pagination with max page sizes, query complexity limits (especially for GraphQL), per-tenant rate limits, request size limits at the edge.
API5: Broken Function Level Authorization
Admin endpoints accessible to non-admin users. Common when the front-end hides the button but the API doesn’t enforce the role. Remediation: deny-by-default authorization on every endpoint; admin endpoints require explicit role check; never rely on URL obscurity.
API6: Unrestricted Access to Sensitive Business Flows
Booking, signup, password reset endpoints abused for ticket scalping, account farming, denial of service. Remediation: business-aware rate limits, CAPTCHA on high-risk flows, behavioral analysis.
API7: Server Side Request Forgery (SSRF)
API takes a URL parameter, fetches it server-side. Attacker provides internal URLs (metadata.aws.com, file://), exfils data. Remediation: allow-list outbound destinations, block IMDS metadata endpoints, use signed URL patterns, IMDSv2 on AWS.
API8: Security Misconfiguration
Default credentials, verbose errors leaking internals, missing security headers, CORS overly permissive (Access-Control-Allow-Origin: * with credentials). Remediation: hardened deployment templates, automated configuration scans, error sanitization.
API9: Improper Inventory Management
“Shadow APIs” — endpoints in production nobody knows about. Old API versions still serving. Test environments with prod data. Remediation: API gateway as authoritative inventory, automated discovery scans, lifecycle management for versions.
API10: Unsafe Consumption of APIs
Your API consumes third-party APIs without validating responses. Compromised upstream → injected data → vulnerable downstream. Remediation: validate all third-party responses; treat them as untrusted input; least-trust integration design.
Discovery — finding the API surface
Before testing, enumerate. Sources:
- OpenAPI/Swagger documents (sometimes public; check
/swagger.json,/openapi.json,/v3/api-docs) - Mobile app traffic capture (covered in Mobile Pentest track)
- JavaScript bundles in the web app — extract API URLs from minified JS
- API gateway management consoles (often publicly indexed)
- Robots.txt, sitemap.xml may leak API paths
- Wayback Machine — historical API endpoints that may still respond
Spec-driven testing
If you have an OpenAPI spec, half your work is done — every endpoint is documented with method, parameters, expected responses. Tools that consume specs:
- Postman / Newman — request crafting + automation
- Schemathesis — generates fuzzed payloads from spec, finds 5xx errors
- OWASP ZAP API scan — DAST that respects the spec structure
- Burp Suite REST API extension — imports spec into Burp’s testing workflow
Auth model audit
For each endpoint, classify auth mode and verify it’s enforced:
- None (public)
- API key (static)
- Bearer token (OAuth/JWT)
- Session cookie
- mTLS
- Signed request (HMAC, AWS SigV4-style)
Common bug: endpoints documented as “requires bearer” but pass with no Authorization header. Test by stripping auth on every endpoint. Surprising number of fails.
Data classification
For every endpoint:
- What does it return — public, internal, confidential, secret?
- What does it write — what’s the blast radius if abused?
- What’s the auth+authz model and is it appropriate to data sensitivity?
Mismatch (high-sensitivity data behind low-strength auth) is the highest-impact finding category.
Where this track goes
Module 2 dives into authentication and authorization patterns — JWT pitfalls, OAuth flows, session management. Module 3 covers GraphQL specifically — it has its own security model and tooling. Module 4 is rate limiting and abuse — the operational defenses. Module 5 is API gateways and zero-trust patterns at scale.