An API sits behind a gateway, users have valid access tokens and all traffic uses HTTPS. Yet an employee might still retrieve another customer’s record. How can that happen when access appears secure?
Imagine a fictional customer portal. An employee may view case 481, changes the identifier in the request to 482 and receives information belonging to another organisation. The token is valid; the gateway forwards the request. But the application never checked whether this user was allowed to read that particular case.
What NIST updated in 2026
The US National Institute of Standards and Technology originally published SP 800-228, Guidelines for API Protection for Cloud-Native Systems, in June 2025. On 13 March 2026, two appendices were added covering categories of API risks and recommended protections across lifecycle phases. The guidance supports risk-based choices; it does not mandate one gateway vendor or product.
A valid token does not grant access to case 482
A gateway can route traffic, secure connections and apply shared limits. An identity provider manages identities and credentials. But neither automatically knows which objects an authenticated caller may read. OWASP describes Broken Object Level Authorization (BOLA): a caller may access an endpoint without being permitted to access every object referenced by an identifier.
In multi-tenant platforms, the application must establish which tenant owns the object, where that context originates and whether the caller can influence it. A tenant ID supplied in an untrusted request is not evidence of permission. Frontend controls cannot replace server-side authorization.
An apparently safe endpoint is not enough
Checking access to one record is a start, not proof that the complete API is secure. Search, list and bulk export endpoints may expose the same data through other paths. Retired API versions or verbose error responses may create further gaps. Enforce relevant object and tenant permissions in each route.
Business rules are another boundary
Someone may be allowed to read a case but not reopen it after closure. A repeated payment request may need idempotency and transactional safeguards. These are not identical to BOLA; they show why identity checks, object authorization and business rules are separate responsibilities. Rate limiting is not a substitute.
Prove what must be denied
Create two users belonging to different tenants in a controlled test environment. With a valid token for tenant A, attempt to read, change and export tenant B’s record. Check denial, the absence of sensitive information in errors or logs, and that no database state was changed. Extend tests to expired tokens, revoked permissions, list filters and repeated requests. Record which layer must reject each attempt.
More layers are not automatically safer
Another proxy or gateway may help standardise controls, but it introduces configuration and maintenance. An internal service has different risks from a public partner API serving many tenants. Document each important control, its owner, and how it is tested. Plan credential rotation, dependency updates and incident monitoring without recording unnecessary personal data or secrets.
Security is visible when a valid request is refused
The decisive test is not whether a valid token passes the gateway, but whether an unauthorized action is correctly rejected. Effective API security depends on enforceable responsibilities and evidence, not the number of products installed.
maintainability and technical debt.
Sources
Contact us
Tell us how we can help; we will respond within two working days.
