REST APIs are now the connective tissue of most modern applications. Mobile clients call them, single page applications depend on them and partners integrate against them. That visibility makes APIs an attractive target for threat actors, who have noticed that API authentication and authorisation often receive less scrutiny than the web pages of the same product. The OWASP API Security Top Ten exists for a reason, and the entries on it appear in real engagements with depressing regularity.
Authentication Is Not Authorisation
The terms get used interchangeably, especially in design documents, and the confusion costs real money. Authentication answers the question of who is calling. Authorisation answers whether that caller is allowed to perform the requested action on the specified resource. A bearer token proves identity. It does not, on its own, prove that the identity is permitted to access whatever object the request mentions. Treating these two concerns as separate, with separate checks at separate layers, is the single biggest improvement most teams can make. A serious web application pen testing on an API surface will probe each of these layers independently.
Object Level Access Control Is Where APIs Bleed
The most common API finding by some distance is broken object level authorisation. An endpoint accepts a record identifier, fetches the record and returns it without checking that the calling identity is allowed to see this specific record. The bug is invisible from outside the application logic and is easy to verify by hand once you suspect it. Every endpoint that accepts an identifier should check ownership. Every single one.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
We routinely find APIs where the front end never lets a user see another customer data and the developers therefore assume the API will never be called with the other customer identifier. The first thing a competent attacker does is change the identifier in the request. The pattern is so reliable it should be the first test on every endpoint.
Documentation Doubles As A Security Control
Good API documentation is a security artefact as well as a developer experience improvement. Documented endpoints get reviewed for security. Undocumented endpoints get forgotten and become shadow APIs. Treat your API documentation as authoritative, regenerate it from the code where possible and use any discrepancy between documentation and reality as a finding worth investigating. Many of the most damaging API breaches involve endpoints nobody had documented and few people knew existed. The documentation also helps incoming team members understand the API faster, which compounds the benefits over time. A well documented API tends to receive more careful security review because reviewers can actually understand what they are looking at.
Logging That Actually Helps
API abuse leaves traces if you log the right things. Successful authentication, failed authorisation, unusual request volumes, anomalous parameter combinations and access to sensitive resources should all be logged with enough context to investigate later. Combine that telemetry with a best pen testing company that performs structured testing across your API surface and you have a meaningful chance of catching abuse before it becomes a breach.
APIs deserve the same testing discipline as the web applications that consume them. They usually get less. That is the gap attackers count on. REST API security comes down to discipline more than novelty. The teams that win do the basics consistently across every endpoint. API security is harder than web application security in some respects and easier in others. The teams that understand the differences and design their controls accordingly tend to produce better outcomes than the ones that simply apply web thinking to API problems.
