Expertise 02 · API security
Know every API you expose, and exactly who can call it
The worst API attacks look like valid requests. I check what you expose, what the edge can enforce and what only your code can fix.
In short
API (application programming interface) security protects the interfaces that web apps, mobile apps and partners use to reach your data. I assess it by comparing discovered APIs with the documented inventory, checking schema enforcement and authentication, and testing object-level authorisation against the OWASP (Open Worldwide Application Security Project) API Security Top 10 (2023). The result separates what the edge can enforce from what must be fixed in code.
What I check
- API inventory against traffic-based discovery
- Shadow, zombie and deprecated API versions
- Schema enforcement at the gateway or WAAP
- Token lifetime, binding and validation
- Object-level authorisation on sensitive endpoints
- Rate limits on OTP, search and export calls
The threats
What this area has to stop.
The attacks I see most often in this area, and what they cost when they land.
Open the attack simulator- Threat 01Broken object-level authorisationA valid user changes an account ID in an API call and receives another customer’s data.One user reads every other customer’s recordsSee which layer stops it
- Threat 02Shadow and zombie APIsAn old or undocumented API version stays live with weaker checks and no monitoring.An open door that nobody is watchingSee which layer stops it
- Threat 03Slow data exfiltrationLegitimate-looking calls page through records a few at a time over weeks.Bulk data loss below every rate limitSee which layer stops it
- Threat 04Excessive data in responsesThe API returns whole objects and relies on the app to hide fields the user should not see.Sensitive fields readable through a proxy
- Threat 05Token and session abuseLong-lived or loosely validated tokens are replayed from another client or device.Account takeover without a password
- Threat 06Unrestricted resource useExpensive searches, huge page sizes or OTP endpoints are called without limits.Outages and runaway messaging costs
The defences
How good looks, layer by layer.
- 01Discovery and inventoryFinds every endpoint taking traffic, documented or not, and names an owner for it.Traffic-based discovery, spec registry
- 02Gateway and rate limitsEnforces authentication, quotas and rate limits before requests reach services.API gateway, WAAP API policy, quotas
- 03Schema enforcementRejects requests, methods and fields that do not match the published specification.OpenAPI validation, positive security
- 04AuthenticationProves who is calling, with short-lived tokens bound to the right client.OAuth 2.0, mutual TLS for partners
- 05Object-level authorisationChecks in code, on every request, that this user may access this specific object.Ownership checks, central policy
Maturity
Where are you on the staircase?
Four levels I use to score this area. Most improvement plans aim one step up within a year.
- L0Unknown estate
- No API inventory; specifications missing or stale
- APIs published straight to the internet
- L1Gateway, no schema
- Some APIs behind a gateway or WAF with rate limits
- Authorisation trusted to the front end or mobile app
- L2Inventoried, enforced
- Discovered APIs reconciled with specs and owners
- Schema validation on; object-level checks tested
- L3Tested every release
- Authorisation tests run in the pipeline per release
- Old versions retired on schedule; drift is alerted
Measure it
Four numbers worth tracking.
- KPI 01Discovered vs documented APIsThe gap between what takes traffic and what is in the inventory is your shadow API count.
- KPI 02APIs with schema enforcementShare of endpoints where requests that break the spec are rejected, not just logged.
- KPI 03Endpoints with authorisation testsSensitive endpoints covered by automated object-level authorisation tests in the pipeline.
- KPI 04Deprecated versions still liveEvery old version is an unmaintained door. Track it until it reaches zero.
Frameworks I assess against
- OWASP API Security Top 10 (2023)
- OpenAPI Specification
Work with me
How I can help with this area.
- WAAP & API protection assessmentI review your WAF, WAAP, bot and API controls against your real estate and traffic, then show the gaps, the bypass paths and a safe route to blocking.2–4 weeksFixed fee
- Application architecture reviewI take one application or platform and trace every path from the internet to its data, then show which controls hold, which are missing and what to fix first.1–3 weeksFixed fee
- API security checklistInventory, authorisation, input controls and monitoring for every API you expose.Free · interactive
Proof from delivery
- 120applications protectedAround 120 applications under WAAP, API and bot protectionManufacturing · A global apparel group headquartered in Sri LankaImpervaRead the case
- 112applications migrated112 bank applications moved to cloud WAAP, wave by waveBanking · A leading Sri Lankan private bankF5 Distributed CloudRead the case
What is BOLA in API security?
BOLA (broken object level authorisation) is the top risk on the OWASP (Open Worldwide Application Security Project) list of API (application programming interface) risks, the API Security Top 10 (2023). It happens when an API checks that a user is logged in but not that they may access the specific object requested, so changing an account or order number returns someone else’s data. It has to be fixed in code, on every request.
What is a shadow API?
A shadow API (application programming interface) is an endpoint that takes live traffic but is missing from the documented inventory: an old version never retired, a test endpoint left exposed, or a route added quietly for the mobile app. Because nobody knows it exists, it is rarely patched, monitored or protected. Traffic-based discovery on a WAAP (web application and API protection) platform or gateway finds them fastest.
Can a WAAP or API gateway fix API security on its own?
No. A WAAP (web application and API protection) platform or API gateway can discover endpoints, enforce schemas, check tokens, apply rate limits and block known attacks. It cannot tell whether user A should see record B, because that request looks valid. Object-level authorisation and business logic must be enforced in the API (application programming interface) code itself.
How do you test APIs for authorisation flaws?
With at least two test users per role. I call each sensitive endpoint as one user while requesting objects that belong to the other, then repeat with changed identifiers, methods and fields. Any response that returns or changes data it should not is a finding. The aim is to turn those cases into automated tests that your pipeline runs on every release.
Where should we start with API security?
Start with the inventory. Compare the APIs (application programming interfaces) your edge platform or gateway sees in live traffic with what the teams have documented, and give every endpoint an owner. Then rank endpoints by the data they return, enforce schemas on the most sensitive ones, and test those for object-level authorisation first. Retire old versions as you go.