API Security & Threat Modeling

APIs are the attack surface of modern systems. Unlike traditional web applications where the server controlled the UI and data flow, APIs expose raw data and operations to any client -- mobile apps, SPAs, third-party integrations, and attackers using curl. The OWASP API Security Top 10 (2023 edition) catalogs the most critical risks: Broken Object Level Authorization (BOLA), Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery (SSRF), Security Misconfiguration, Improper Inventory Management, and Unsafe Consumption of APIs.

The most common API vulnerability is Broken Object Level Authorization (BOLA, also known as IDOR -- Insecure Direct Object Reference). An API that returns /api/orders/123 checks authentication (is the caller logged in?) but not authorization (does the caller own order 123?). An attacker changes the ID to 124, 125, 126 and retrieves other users' orders. BOLA is trivial to exploit and devastatingly common because authorization checks require per-resource logic that is easy to forget.

Threat modeling is the practice of systematically identifying what can go wrong before it happens. The STRIDE framework classifies threats into six categories: Spoofing (impersonating a user or service), Tampering (modifying data in transit or at rest), Repudiation (denying an action without proof), Information Disclosure (exposing sensitive data), Denial of Service (overwhelming a system), and Elevation of Privilege (gaining unauthorized access). For each API endpoint, you enumerate applicable STRIDE threats and design mitigations.

Input validation is the first line of defense. Every API endpoint must validate: type (is this field a string, number, enum?), length (is this string under 10,000 characters?), format (is this a valid email, UUID, date?), range (is this quantity between 1 and 1000?), and business rules (is this product ID in the catalog?). Validation should happen at the API boundary (before business logic) and produce clear error messages. Never trust client-side validation -- it can be bypassed.

Defense-in-depth combines multiple security layers: TLS for confidentiality, authentication for identity, authorization for permissions, input validation for data integrity, rate limiting for availability, and logging for auditability. No single layer is sufficient -- each catches threats that others miss.

An e-commerce API has GET /api/orders/{id}. The endpoint checks the JWT (authentication) but returns any order by ID without checking if the caller owns it (missing authorization). Alice, logged in as user_123, calls GET /api/orders/456 and receives Bob's order details (address, items, payment method). Alice iterates IDs from 1 to 100,000 and scrapes the entire order database. Fix: the endpoint must check order.user_id == jwt.sub before returning data.