Are Your APIs Wide Open? The 5 Fatal OWASP API Top 10 Mistakes

## APIs: The Back Door Nobody's Watching

Your frontend can be armored. Your login can have MFA. But if the API returning customer data accepts any call without validating permissions, **everything you've built is security theater**.

### The 5 Most Devastating Mistakes (Based on OWASP API Security Top 10)

#### 1. BOLA — Broken Object Level Authorization
The most common and most dangerous error. User A can access User B's data by simply changing the ID in the URL: `/api/users/123` → `/api/users/456`.

**How to test:** Intercept the request with Burp Suite, swap IDs, and see if it returns another user's data.

#### 2. Weak Authentication on Internal Endpoints
Internal APIs are often "protected" only by being on a private network. With an SSRF (Server-Side Request Forgery), an attacker can access them from outside.

#### 3. Excessive Data Exposure
The API returns ALL object fields (including `password_hash`, `internal_notes`, `credit_card_token`) and trusts the frontend to filter. **Never trust the frontend.**

#### 4. No Rate Limiting
Without rate limiting, an attacker can brute force credentials, enumerate users, or exfiltrate the entire database with mass API calls.

#### 5. Parameter Injection
SQL Injection, NoSQL Injection, and even GraphQL Injection continue to devastate APIs that don't validate and sanitize inputs.

### API Hardening Checklist

- [ ] Authorization on EVERY endpoint (don't rely on global middleware alone)
- [ ] Rate limiting per IP and per token (3-5 req/s for sensitive endpoints)
- [ ] Minimal response: return ONLY the necessary fields
- [ ] Input validation with strict schemas (Zod, Joi, JSON Schema)
- [ ] Logging ALL unauthorized access attempts
- [ ] API Gateway with WAF (Web Application Firewall)

> **At RET, every API undergoes automated BOLA testing, parameter fuzzing, and SAST/DAST analysis before going to production. API security isn't a feature — it's a prerequisite.**