The gap between "authenticated" and "authorized"
Here is a failure we run into again and again during security assessments. An API validates its credentials perfectly. Every request carries a valid token, the signature checks out, the key is on the allow-list. On paper the authentication is flawless. Then a tester changes a single number in the request path, swaps account 1042 for account 1043, and the API happily returns someone else's data. The credentials were verified. Whether those credentials were allowed to touch that specific record was never checked.
That one gap, authentication working while authorization is absent, sits at the top of the OWASP API Security Top 10 as Broken Object Level Authorization. It is not exotic. It is the most common serious flaw we find, and it rarely shows up in a demo because the happy path looks fine. You only see it when someone goes looking, and by then it may be an attacker rather than a tester.
APIs now carry most of the traffic that matters to a business: mobile apps, partner integrations, internal microservices, and the growing population of AI agents calling tools on a schedule. That shift has made them the primary target. According to Akamai's 2026 State of the Internet report, 87% of organizations experienced an API-related security incident during 2025, and the average number of daily API attacks per organization climbed 113% year over year, from 121 to 258. The same report found that security misconfiguration accounted for 40% of exploited APIs, broken object property level authorization for 35%, and broken authentication for 19%.
Those three numbers tell you where to spend your effort. Below is how we approach API security in the field, the controls that actually move the risk needle, and where each one fits.
Why APIs are harder to secure than the apps in front of them
A traditional web application has a front door. Users arrive through a browser, sessions are managed in one place, and a web application firewall can watch a fairly predictable stream of requests. APIs break that model. A single product might expose hundreds of endpoints across REST, GraphQL, and gRPC, each with its own parameters, each speaking directly to backend data. Many were built by different teams over different years, and some were never written down anywhere.
Three properties make APIs a distinct problem:
- They expose business logic directly. An endpoint like POST /transfers is not a page, it is a function that moves money. Attackers do not need to find a clever exploit when they can abuse the documented behaviour of the function itself.
- They are machine-to-machine. There is no human to notice something looks off. A script can iterate through object IDs thousands of times a minute, and without rate controls and anomaly detection, nothing stops it.
- They drift out of inventory. Versions accumulate. A v1 endpoint stays live years after v3 shipped, still reachable, no longer patched. Akamai's report noted organizations run an average of roughly 3,000 APIs handling sensitive data, and about 12% of them carry known weaknesses. You cannot protect what you have not catalogued.
In our engagements, the discovery phase, simply finding every endpoint that exists, routinely surfaces more risk than any single vulnerability scan. Shadow and zombie APIs are where breaches hide.
Authorization is the control most teams get wrong
Authentication answers "who is calling." Authorization answers "is this caller allowed to do this specific thing to this specific resource." Teams invest heavily in the first and treat the second as an afterthought, which is exactly backwards relative to where the incidents come from.
The OWASP list breaks authorization failures into three separate entries because they fail in different places:
- Broken Object Level Authorization (API1): the caller reaches an object they should not, usually by manipulating an ID in the URL, body, or query string.
- Broken Object Property Level Authorization (API3): the caller reads or writes fields they should not, for example setting "role": "admin" in an update payload that the server accepts without checking.
- Broken Function Level Authorization (API5): a standard user calls an administrative endpoint that was never meant to be exposed to them, because access was enforced in the UI rather than the API.
The fix is unglamorous and it works: enforce authorization on the server, on every request, against the authenticated identity, at the level of the individual object and field. Never trust an ID supplied by the client as proof of ownership. Never rely on the front end to hide a function. Where you can, drive authorization from a central policy engine rather than scattering if statements through every controller, so the rules are auditable and consistent. Open Policy Agent and similar policy-as-code approaches let you keep that logic in one reviewable place.
A layered set of controls
No single product secures an API. The teams that hold up well combine several layers, each covering what the others miss.
Strong identity and short-lived tokens
Move away from static, long-lived API keys wherever the design allows. OAuth 2.1 with short-lived access tokens and rotating refresh tokens gives you revocation and scope. Validate the token signature, issuer, audience, and expiry on the resource server every time, not just at the gateway. For service-to-service calls inside the estate, mutual TLS (mTLS) proves both ends of the connection and is now standard practice in the banking and telecom environments we work in. In a zero-trust design, every hop authenticates, including the ones inside your own network.
An API gateway at the edge
A gateway, whether Kong, Apigee, AWS API Gateway, or an equivalent, gives you a single point to enforce authentication, apply rate limits, terminate TLS, and emit consistent logs. It is also where a Web Application and API Protection (WAAP) layer inspects traffic for injection, credential stuffing, and known bad patterns. The gateway is necessary but not sufficient. It sees the request, not the business context, so it cannot decide whether user 1042 owns record 1043. That decision stays with the service.
Rate limiting and abuse prevention
Unrestricted resource consumption (API4) and abuse of sensitive business flows (API6) are about volume and pattern, not a single malformed request. Rate limits per client and per endpoint, quotas, request-size caps, and pagination limits blunt scraping and enumeration. Bot management and behavioural analysis catch the automated workflows that Akamai found made up 61% of API attacks in 2025. A login endpoint that accepts unlimited attempts is a credential-stuffing target no matter how good your password policy is.
Input validation and schema enforcement
Validate every request against a strict schema and reject anything that does not conform. For REST, that means an OpenAPI definition enforced at runtime, not just published in documentation. Positive validation, allowing only what you expect, stops a wide class of injection and mass-assignment problems before they reach your code. This is also the control that closes the property-level authorization gap: if the schema does not permit a client to send role, the server never processes it.
Visibility feeding your SOC
You cannot respond to what you cannot see. Every API request and its authorization decision should produce structured logs that flow into your SIEM. Baseline normal behaviour per endpoint, then alert on deviations: a client suddenly walking sequential IDs, a spike in 403s that signals probing, a token used from two continents in one minute. This is where API security stops being a one-time hardening exercise and becomes an operational discipline your security operations centre runs day to day.
Mapping the OWASP risks to concrete controls
It helps to see the current OWASP API Security Top 10 (2023 edition, still the active version) alongside the control that addresses each item. This table is the backbone of the assessments we deliver.
OWASP API risk (2023)What goes wrongPrimary control
API1 Broken Object Level Authorization
Caller accesses another user's object by changing an ID
Server-side ownership check on every object, every request
API2 Broken Authentication
Weak tokens, no expiry, guessable credentials
OAuth 2.1, short-lived tokens, full token validation, MFA on issuance
API3 Broken Object Property Level Authorization
Reading or writing fields the caller should not touch
Strict schema validation, explicit field allow-lists
API4 Unrestricted Resource Consumption
No limits on rate, size, or cost of requests
Rate limits, quotas, payload and pagination caps
API5 Broken Function Level Authorization
Regular users reaching admin functions
Role and function checks enforced in the API, not the UI
API6 Unrestricted Access to Sensitive Business Flows
Automation abusing legitimate flows (bulk purchase, signup)
Bot detection, behavioural analysis, step-up verification
API7 Server Side Request Forgery
API fetches an attacker-supplied URL
Allow-list outbound destinations, validate and isolate
API8 Security Misconfiguration
Default settings, verbose errors, open CORS
Hardened baselines, CIS Benchmarks, config as code
API9 Improper Inventory Management
Forgotten versions and undocumented endpoints
Continuous API discovery, versioning and deprecation policy
API10 Unsafe Consumption of APIs
Blindly trusting data from third-party APIs
Validate upstream responses, treat partners as untrusted
Two rows on that list, API8 and API9, correspond directly to the two categories Akamai found most exploited in 2025. Misconfiguration and unmanaged inventory are not the most sophisticated risks. They are the most common because they are the ones organizations forget to own.
Where compliance fits
Most of our clients operate under one or more frameworks, and API security maps onto them cleanly rather than sitting off to the side. For any API that touches cardholder data, PCI-DSS 4.0 pushes hard on authenticated access, strong cryptography in transit, and logging, all of which are API controls. ISO 27001 Annex A controls around access management and secure development apply to every endpoint you expose. The NIST Cybersecurity Framework gives you a structure for the operational side, with Identify covering API inventory, Protect covering the controls above, and Detect and Respond covering the SOC work. CIS Benchmarks give you the hardened baselines that close the misconfiguration gap.
The practical value of tying API security to these frameworks is that it turns a technical backlog into something an audit and a board will fund. "Fix our BOLA issues" is a hard sell to a budget holder. "Meet PCI-DSS 4.0 requirement 6 and 8 across our payment APIs" is not.
An API security readiness checklist
When we scope an engagement, this is roughly the order we work through. It doubles as a self-assessment you can run internally before bringing anyone in.
- Discover and catalogue every API, including old versions, internal services, and anything exposed by third-party components. You cannot secure an unknown endpoint.
- Confirm authentication on every endpoint and remove or gate anything unauthenticated that touches data.
- Enforce object-level and function-level authorization on the server, checked against the caller's identity, on every request.
- Replace long-lived static keys with short-lived tokens and scopes; require mTLS for internal service traffic.
- Apply strict schema validation with allow-lists for fields and inputs.
- Set rate limits, quotas, and payload caps per client and per endpoint.
- Harden configuration against CIS Benchmarks and remove verbose error output and permissive CORS.
- Route all API logs and authorization decisions into your SIEM and baseline normal behaviour.
- Add API security tests to the CI/CD pipeline so regressions are caught before release, not after.
- Establish a versioning and deprecation policy so retired endpoints actually go away.
Shift the work left, then keep watching
The cheapest place to fix an API flaw is before it ships. In a DevSecOps pipeline, that means static analysis on the code, dynamic API testing against a running build, and schema and contract checks running automatically on every merge. A broken authorization check should fail a build the same way a failing unit test does. We help teams wire these gates in so security is part of the pipeline rather than a review that happens after the fact.
Testing before release is necessary, and it is not the whole job. APIs change, new endpoints appear, and attacker behaviour shifts. The organizations that stay ahead pair pre-release testing with runtime monitoring, so a control that quietly breaks in production, or an endpoint that appears without going through review, gets caught in operations. That combination, shift-left testing plus runtime detection, is what "continuous" actually means when people say continuous API security.
How Aydahwa Enterprise can help
We work with organizations in banking, telecom, and critical national infrastructure, sectors where an exposed API is not an inconvenience but a regulated event. Our approach starts with discovery, because in our experience the endpoints a client does not know about carry more risk than the ones already on the radar. From there we assess against the OWASP API Security Top 10, map findings to whichever framework governs you, whether PCI-DSS 4.0, ISO 27001, NIST CSF, or CIS Benchmarks, and hand back a prioritized plan rather than an undifferentiated list of findings.
The team holds credentials including the Microsoft Cybersecurity Architect Expert certification and brings 25 years of hands-on infrastructure and security architecture across UNIX, Linux, cloud, and network design. That background matters for API work specifically, because securing an API is as much about the gateway, the network path, and the identity plumbing as it is about the code.
If you want to see where you stand, our free cybersecurity self-assessment and readiness checklist are a fast starting point. For a deeper review of your API estate, our cybersecurity services and cloud security and migration practices cover assessment, remediation, and the DevSecOps pipeline work that keeps the gains in place. When you are ready to talk specifics, get in touch and we will scope it around the systems you actually run.
