Notifications
Clear all
Topic starter
02/08/2026 9:41 am
TL;DR: REST APIs remain exposed to enumeration, BOLA, weak token handling, and injection paths because predictable URLs and stateless request flows make authorization and validation failures easy to exploit, according to StackHawk’s REST API Security: Best Practices Guide. The practical issue is not whether APIs can be tested, but whether teams enforce request-level controls, logging, and gateway policy before production exposure.
NHIMG editorial — based on content published by StackHawk: REST API Security: Best Practices Guide
By the numbers:
- According to the OWASP API Security Top 10, Broken Object Level Authorization (BOLA) remains the #1 API security risk.
Questions worth separating out
Q: What breaks when REST APIs rely on authentication without object-level authorisation?
A: Authentication proves who made the call, but not whether that caller should access the specific object requested.
Q: Why do REST APIs make enumeration and access abuse easier than many other architectures?
A: REST often exposes predictable resource paths and sequential identifiers, which gives attackers a map to probe.
Q: How can security teams tell whether API risk controls are actually working?
A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why.
Practitioner guidance
- Enforce object-level ownership checks Require every read, update, and delete path to verify the requester owns the target object or has an explicitly delegated scope.
- Treat API keys and JWTs as governed NHI credentials Assign each integration its own credential, define expiry and rotation rules, and revoke access when the integration is no longer needed.
- Move request validation to both edge and code Use the gateway to block malformed requests, enforce content types, and apply rate limits, then keep business-rule checks in application code for ownership, scope, and field-level permissions.
What's in the full article
StackHawk's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples for implementing TLS, mTLS, and gateway policy across REST services
- Code-level patterns for JWT validation, request ownership checks, and allowlist-based input handling
- Practical rate limiting, logging, and error-handling guidance for production APIs
- StackHawk’s testing workflow for finding BOLA, injection, and auth bypass issues in CI/CD
👉 Read StackHawk's REST API security best practices guide →
REST API security gaps: are your auth and validation controls keeping up?
Explore further
02/08/2026 12:35 pm
REST API security is increasingly an identity problem as much as an application problem. The guide correctly centres authentication, authorisation, and token handling because APIs are now a primary way humans, services, and automation prove identity to each other. That means IAM and NHI governance must extend beyond login flows into every API call path. Practitioners should treat API policy as part of identity control design, not as a separate web security checklist.
A question worth separating out:
Q: Should organisations govern API keys and service tokens like other non-human identities?
A: Yes. API keys, service tokens, and similar credentials are non-human identities in operational terms because they grant machine-to-machine access and can persist far beyond a single user session. They need ownership, scope limits, rotation, revocation, and monitoring. Treating them as ad hoc secrets is how stale access and blind spots accumulate.
👉 Read our full editorial: REST API security gaps persist as authorization and input checks fail
