Every app you touch is quietly making API calls. The banking app checking your balance, the airline site pulling fares, the SaaS dashboard stitching together five other tools: all of it rides on APIs, and most traffic on the modern web is now machine-to-machine rather than a person loading a page. Attackers noticed.
The uncomfortable part is how unglamorous the breaches are. When Optus exposed the records of roughly 9.8 million Australians in 2022, and when an attacker pulled data on about 37 million T-Mobile accounts through a single API in early 2023, the root cause was not an exotic zero-day. It was an API that handed back data to anyone who asked, in the right shape, with the right ID. API security is mostly the discipline of making sure that never happens.
What API security covers
API security is the set of practices, controls and protocols that keep your APIs from being abused: unauthorized access, data leakage, denial-of-service and the quieter business-logic attacks that look like ordinary traffic. It spans the entire life of an API, from how it is designed and authenticated to how it behaves under load in production.
It overlaps with general application security but is not the same thing. A traditional web application firewall is tuned to catch injection and cross-site scripting in form fields and URLs. APIs fail differently. The damaging bugs are usually logic flaws: an endpoint that trusts a client-supplied ID, a token that never expires, an admin function left reachable by a normal user. A signature-based filter scanning for SQL keywords sails straight past all of it.
Why APIs became the favourite target
Three things happened at once. Architectures fragmented into microservices, so a single product might expose hundreds of internal and external endpoints. Front ends moved to mobile apps and single-page web apps that talk to back ends purely over APIs. And companies began publishing APIs to partners and customers as products in their own right. The attack surface multiplied, and a lot of it was never inventoried.
The result is sprawl: shadow APIs nobody documented, zombie versions left running after a redesign, staging endpoints that quietly went public. OWASP took the problem seriously enough to publish a dedicated API Security Top 10, separate from its flagship web list, precisely because the risk profile is different. The headline finding has held across editions. The worst API bugs are authorization bugs.
The OWASP API Security Top 10
The 2023 edition is the reference most teams work from. It rewards reading end to end, but here is the shape of it.
| Risk | What goes wrong |
|---|---|
| Broken Object Level Authorization (BOLA) | An endpoint returns or changes an object based on an ID the client supplies, without checking the caller owns it. Swap the ID, get someone else's data. The single most common and damaging API flaw. |
| Broken Authentication | Weak or missing login controls: guessable tokens, no expiry, credential stuffing, unprotected token endpoints. |
| Broken Object Property Level Authorization | The endpoint exposes or accepts fields the caller should not see or set, such as returning a password hash or letting a user flip their own role to admin. |
| Unrestricted Resource Consumption | No rate limits or quotas, so a caller can hammer the API into a denial of service or run up huge compute and bandwidth costs. |
| Broken Function Level Authorization | Admin or privileged functions reachable by ordinary users because the route is not gated by role. |
| Unrestricted Access to Sensitive Business Flows | Automation abuses a legitimate flow at scale: bulk-buying limited stock, mass account creation, scraping. |
| Server-Side Request Forgery (SSRF) | The API fetches a URL the caller supplies without validating it, letting an attacker reach internal systems. |
| Security Misconfiguration | Default settings, verbose error messages, missing security headers, permissive CORS, unpatched components. |
| Improper Inventory Management | Undocumented, deprecated or shadow APIs running unmonitored. You cannot defend what you do not know exists. |
| Unsafe Consumption of APIs | Trusting data from third-party APIs too readily and inheriting their weaknesses. |
Notice how many of those are about authorization rather than encryption or injection. BOLA sits at number one for a reason. It is trivial to introduce, hard to catch with automated scanners, and devastating when exploited, because the malicious request looks completely valid. The fix is unglamorous and non-negotiable: check ownership on every object, on every request, on the server.
Authorization is where most breaches live
Authentication and authorization get blurred together, and the distinction matters. Authentication answers who you are. Authorization answers what you are allowed to touch. APIs tend to get the first one roughly right and the second one badly wrong.
For authentication, the modern baseline is OAuth 2.0 with OpenID Connect for identity, short-lived signed tokens, and multi-factor authentication on anything sensitive. JSON Web Tokens are everywhere and easy to misuse: tokens that never expire, signing secrets committed to a repo, or a server that accepts an unsigned token because it never verifies the algorithm. For service-to-service calls, mutual TLS pins both ends of the conversation.
Authorization is the harder half. Role-based and attribute-based access control define who can call what, but the bug that keeps leaking data is finer-grained than roles. It is the object-level check: when a request asks for invoice 1042, does the code confirm this caller owns invoice 1042, or does it just fetch it? Never trust an ID, a field or a flag because it arrived in the request. Enforce least privilege, and verify ownership in the code path that touches the data, not in the client.
Controls that move the needle
No single product secures an API. A workable stack layers a few controls, each covering what the others miss.
- An API gateway as the front door. Centralise authentication, rate limiting, routing and logging instead of reimplementing them in every service.
- Encryption in transit and at rest. TLS on every endpoint, no exceptions, plus encryption for stored sensitive data.
- Positive schema validation. Validate every request against an OpenAPI contract and reject anything that does not fit, rather than blocklisting known-bad input.
- Rate limits and quotas. Throttle per client and per endpoint to blunt scraping, credential stuffing and resource-exhaustion attacks.
- Logging, monitoring and anomaly detection. Feed structured API logs into a SIEM or SOC so abuse that looks like valid traffic still gets flagged.
- Secrets management. Keep API keys and tokens out of source code and client bundles, rotate them, and scope them tightly.
This is also where the market has shifted from the classic web application firewall toward broader Web Application and API Protection, or WAAP, which adds API-aware schema enforcement, bot mitigation and abuse detection. Useful, as long as it is not mistaken for a substitute for fixing the code.
Find your APIs before attackers do
Improper inventory management earns its place on the OWASP list because it is so common. Most organisations underestimate how many APIs they run. Old versions linger after a redesign. A team ships an internal endpoint that drifts into production exposure. Documentation lags reality.
You cannot protect what you cannot see, so discovery comes first. Catalogue every API, internal and external, with an owner, a version and a documented contract. Retire deprecated versions deliberately instead of leaving them to rot. Treat the inventory as living infrastructure, because a forgotten endpoint running a stale authentication model is exactly the door an attacker goes looking for.
Shift left, then watch at runtime
Good API security starts in design and never stops. Threat-model the API before it is built, validate the contract, and run static analysis, dynamic testing and dependency scanning in the pipeline so obvious flaws die in CI rather than in production. This shift-left discipline is cheap insurance.
But design-time testing cannot see business-logic abuse. A scanner will not notice that a legitimate checkout flow is being driven by a bot ten thousand times a minute, or that one account is quietly enumerating object IDs. That is a runtime problem, and it needs runtime telemetry, behavioural detection and a team that watches. The mature posture is zero trust applied to APIs: authenticate and authorize every call, trust no network position, and assume any client can be hostile.
Where to start
For a team staring at an unsecured estate, the order matters more than the tooling.
- Inventory everything. You cannot secure APIs you have not found.
- Fix authorization first. Hunt for BOLA and broken function-level access; these cause the worst breaches.
- Put a gateway in front. Consolidate authentication, TLS, rate limiting and logging at one control point.
- Validate inputs against a schema. Reject anything that does not match the contract.
- Watch production. Log to a SIEM and add anomaly detection for abuse that passes authentication.
None of this is exotic. API security rewards boring discipline far more than clever tooling: know what you run, check who is allowed to touch what, encrypt the traffic, limit the abuse and watch what happens. The attacks that make the news almost always trace back to one of those basics being skipped.
Need help securing your APIs?
Browse cybersecurity specialists and API platform vendors in the TechDirectory.
Frequently asked questions
What is API security?
API security is the practice of protecting application programming interfaces from unauthorized access, data exposure, denial-of-service and business-logic abuse, across the full life of the API from design to runtime. It centres on strong authentication, strict authorization, encryption, rate limiting and monitoring.
What is the OWASP API Security Top 10?
It is a community-maintained list of the ten most critical API security risks, published separately from the main OWASP Top 10. The current 2023 edition is led by Broken Object Level Authorization (BOLA) and also covers broken authentication, excessive permissions, unrestricted resource consumption, server-side request forgery, misconfiguration and poor API inventory.
What is the difference between API security and a web application firewall?
A web application firewall inspects traffic for known attack patterns such as SQL injection and cross-site scripting. Most serious API breaches are authorization and business-logic flaws that look like valid requests, which a signature-based firewall misses. API security layers object-level access checks, schema validation, API-aware abuse detection and inventory management on top of perimeter filtering.
What is BOLA and why is it the top API risk?
Broken Object Level Authorization happens when an API returns or modifies an object based on an ID the client supplies, without confirming the caller owns it. Changing the ID exposes another user's data. It tops the list because it is easy to introduce, hard for automated scanners to detect, and the malicious request looks completely legitimate.
How do I secure a REST API?
Authenticate with OAuth 2.0 and OpenID Connect, use short-lived signed tokens, and enforce object-level authorization on every request. Put an API gateway in front for TLS, rate limiting and logging, validate inputs against an OpenAPI schema, keep secrets out of code, and monitor production traffic for abuse. Maintain an inventory so no endpoint runs unwatched.
Is an API gateway enough to secure APIs?
No. A gateway centralises authentication, rate limiting and TLS, but it will faithfully forward a valid request to a service whose own authorization logic is broken. Gateways are an important control, not a complete solution. The access checks still have to be correct inside each service.