API Security Beyond the WAF: Rate Limiting, Authentication, and Schema Validation

A WAF is your first line of defense for web applications — but APIs need more. API security requires multiple layers working together: the WAF catches known attack patterns, but rate limiting, authentication, and schema validation handle threats the WAF can't see.

Why WAFs Struggle with APIs

WAFs are designed to detect attack signatures in HTTP requests — SQL injection patterns, XSS payloads, known exploit strings. This works well for traditional web apps. But APIs present different challenges:

• Legitimate-looking attacks: A BOLA (Broken Object Level Authorization) attack looks like a normal API call — just with a different object ID. No signature to detect.
• Business logic abuse: A user calling an endpoint 10,000 times to scrape data isn't using an attack payload. It's just volume.
• Schema violations: Sending a string where an integer is expected, or 500 fields when the API expects 5 — these bypass signature-based WAFs.

Layer 1: Rate Limiting

Rate limiting is the most basic API protection. It prevents brute force, scraping, and denial-of-service attacks at the application level. But naive rate limiting (X requests per minute per IP) doesn't work:

• Per-user, not per-IP: Behind a corporate NAT, thousands of users share one IP. Behind a botnet, one user has millions of IPs. Rate limit by authenticated user, not IP.
• Endpoint-aware: A login endpoint needs stricter limits than a read-only product listing. Set per-endpoint limits.
• Adaptive: If traffic spikes during a known event (product launch, sale), adaptive limits can temporarily raise thresholds. Static limits break legitimate traffic.

Layer 2: Authentication and Authorization

Most API vulnerabilities aren't about bypassing the WAF — they're about broken authentication and authorization. The 2024 OWASP API Security Top 10 lists Broken Object Level Authorization (BOLA) as the #1 risk.

Every API endpoint needs:

• Authentication: Verify the caller is who they claim to be (OAuth 2.0, API keys, JWT)
• Authorization: Verify the caller has permission to perform the requested action on the requested resource
• Object-level checks: Just because user A is authenticated doesn't mean they can access user B's data

A WAF can't enforce authorization. It doesn't know your business logic. This is application-level code — and no amount of WAF rules can replace it.

Layer 3: Schema Validation

API schema validation ensures incoming requests match the expected structure. If your API expects `{"email": "string", "amount": "number"}`, it should reject anything else — extra fields, wrong types, or malformed data.

Schema validation catches:

• Mass assignment attacks (sending extra fields to overwrite protected attributes)
• Type confusion (sending an object where a string is expected)
• Prototype pollution (in Node.js APIs)
• Unexpected content types

Implement schema validation at the API gateway or in your application framework. OpenAPI/JSON Schema validation at the edge stops malformed requests before they reach your application logic.

How They Work Together

The layers stack: WAF catches attack signatures → rate limiting prevents volume attacks → authentication verifies identity → authorization checks permissions → schema validation enforces structure → application logic handles the request.

Each layer catches different threats. Remove one, and attackers will find the gap. A WAF without rate limiting is useless against a slow scraping attack. Rate limiting without authentication is useless against authenticated abusers. Authentication without authorization is useless against BOLA.

Test each layer independently. Use WAFNinja for WAF bypass testing. Use load testing tools for rate limit validation. Use manual pentesting for authorization logic. No single tool covers everything — and no single security layer does either.