The Threat Model
Public APIs are rarely threatened by just one thing. They usually face a mix of:
- brute-force abuse
- bot-driven account actions
- injection attempts
- cross-site request forgery on browser clients
- generalized endpoint hammering
That is why one control is never enough. Defense in depth is not a slogan. It is an admission that every individual layer can fail.
Layer 1: Edge or Gateway Controls
The first layer should absorb the most mechanical abuse:
- coarse rate limiting
- challenge rules
- TLS enforcement
- request filtering before the application executes
This is the best place to stop obvious junk because it prevents waste further downstream.
Layer 2: Reverse Proxy Controls
A second layer at the proxy or ingress tier adds useful redundancy.
It can:
- apply route-specific limits
- separate write-heavy and read-heavy traffic
- enforce internal routing boundaries
- narrow which networks can reach backend services
This layer matters because a security model should not collapse if one gateway rule is bypassed or misconfigured.
Layer 3: Application-Level Limiters
The application still needs its own view of abuse.
That is where you typically want:
- per-endpoint limiters
- per-user or per-IP counters
- category-specific thresholds
- shared counters across instances via an external store
Application-level rate limiting provides the finest control because the app understands intent, not just path patterns.
Request Sanitization
Input sanitization is still necessary even in strongly typed applications.
For document databases, operator injection is a classic example. If user-controlled objects are allowed to carry query operators, application assumptions collapse quickly.
The fix is not complicated:
- validate structure
- strip dangerous keys
- recurse into nested objects when needed
- constrain string length and allowed content
Security here comes from boring consistency, not cleverness.
Browser Security Controls
If a browser client authenticates with cookies, the application must defend the browser-specific attack surface.
That includes:
- strict security headers
- clickjacking protection
- transport enforcement
- CSRF protection for state-changing routes
CSRF tokens should be compared using timing-safe logic. Otherwise the token check itself can leak information.
Bot Controls on Sensitive Endpoints
Some routes deserve challenge-based bot friction:
- account creation
- password reset
- credential recovery
- other abuse-prone write endpoints
These controls are most effective when combined with rate limiting rather than treated as a substitute for it.
Network Isolation
Security posture improves dramatically when data services are not exposed on the same surface as application services.
A healthy baseline is:
- backend reachable only through an internal gateway or controlled network path
- database not publicly exposed
- cache not publicly exposed
This reduces the blast radius if an application service is compromised.
Logging Without Leaking
Good observability often turns into accidental data disclosure if logs are not treated carefully.
Sensitive material should never be written to logs:
- credentials
- token values
- connection strings
- personal data that is not operationally necessary
Structured logging is most useful when it provides traceability without turning your log pipeline into a secondary secrets store.
Design Lessons
- Edge filtering, proxy controls, and app limiters solve different problems.
- Sanitization is still essential even in typed codebases.
- Browser authentication requires browser-specific defenses.
- Sensitive account flows deserve challenge-based friction.
- Security logging should maximize diagnosis while minimizing data exposure.