Every time you open an application, far more happens than what reaches the screen. Check the forecast, and your phone never measured the temperature outside; it asked a weather service for the latest reading. Sign in to a new site with your Google account, and that site never sees your password; it asks Google to vouch for you. Each of these exchanges travels through an application programming interface, or API, and a single tap can set off dozens of them in the background.
APIs are the connective tissue of modern software, and they have quietly become one of the largest and least understood parts of an organization's attack surface. Before we get to why they draw attackers and how to defend them, it helps to know what an API actually is.
What is an API?
An API is a set of rules that lets one piece of software request data or an action from another, in a format both sides agree on in advance. It defines which requests are allowed, how each must be phrased, what information it carries, and what shape the answer comes back in.
Picture a single exchange. The program making the request is the client, and the program answering is the server. The client sends a request to a specific address exposed by the API, called an endpoint, and the server performs the work behind that endpoint and returns a response, usually a block of structured data. The client never needs to know how the server works inside; they only need to know how to ask and how to read the answer.
That separation is why APIs are everywhere. A team building a product doesn't have to write its own mapping engine, payment processor, or login system; it can call a service that already does those things and use the results. A typical app is stitched together from many such calls, some to services the organization owns and some to third parties. That reach is also why securing them is its own discipline: an application's safety now depends on every door it opens to the outside.
The main types of APIs
APIs come in several architectural styles, and the differences shape how data moves and where security attention goes. Four types cover most of what you'll meet.
REST (representational state transfer) is behind most web APIs today. It uses ordinary HTTP methods to act on resources named by a URL: roughly, GET to read, POST to create, PUT to update, and DELETE to remove. It is stateless, meaning each request carries everything the server needs, and it usually sends data as JSON, a lightweight text format. REST has no security of its own; protection is added through how the API is designed and deployed.
SOAP (simple object access protocol) is older and stricter. It wraps messages in XML and carries standardized security extensions, known as WS-Security, that can sign and encrypt individual messages. It remains common in banking and payments, where compliance demands are high. It is worth being precise here, since some descriptions imply that SOAP is secure by default: the standards exist, but they must still be implemented correctly to provide any protection.
GraphQL exposes a single endpoint and lets the client ask for exactly the fields they want. That flexibility cuts wasted data, but it shifts work to the server, which must handle queries whose cost it cannot fully predict. A deeply nested or batched query can demand far more than its simple appearance suggests, so GraphQL APIs lean on query-depth limits and timeouts.
RPC (remote procedure call) styles, including modern gRPC, allow a client to call a function on a remote server as if it were running locally. They suit tightly coupled internal services where speed and a fixed contract matter more than broad compatibility.
What is API security?
If APIs are the doors between software systems, API security is the practice of ensuring that only the right people come through them, carry only what they are allowed to carry, and that no one can prop a door open or slip through one left unlocked. Put more precisely, API security is the set of practices and controls that protect APIs from unauthorized access, data exposure, abuse, and disruption throughout their lifecycle, from design through retirement.
Many definitions circle back on themselves, describing the field as "security for your APIs." The substance is in what is protected: the confidentiality, integrity, and availability of the data and services an API exposes.
An API does not protect itself simply because the application behind it has a login screen or sits behind a firewall. APIs expose application logic and data directly, often to clients the organization does not control, and they tend to honor any request that arrives correctly formatted and authenticated, even one crafted to reach something it never should. Securing an API means scrutinizing each request on its own terms: who is asking, whether they may perform this action on this data, and whether the request attempts to do something the API was never meant to allow.
How is API security different from application security?
API security is part of application security, but APIs are built and attacked differently enough that treating them as ordinary web pages leaves gaps. Three differences stand out:
The first is the size and shape of the attack surface. A traditional web application is built mainly for one kind of visitor, a person at a browser, and much of its defense concerns how that person's input is handled on screen. An API serves many clients at once: mobile apps, web frontends, partner systems, internal services, and other APIs. Every endpoint is another way in (APIs expose many of them), and teams add and change endpoints constantly, so the surface is larger and more fluid.
The second is how identity is established. Web applications lean on sessions and cookies, often backed by a two-factor prompt that a human can answer. APIs usually authenticate with tokens or keys passed in each request, such as OAuth tokens or JSON Web Tokens. An API token is often the sole factor separating an attacker from an account, with no human present to answer a second challenge, making stolen or forged tokens especially valuable and automated abuse harder to distinguish from legitimate traffic.
The third difference matters most. Classic web attacks were often "one and done," a single request carrying a known payload aimed at a known weakness. Those still happen, but the costliest API attacks look different. Because every API encodes its own business logic, the most serious attacks are slow, patient abuses of that logic rather than off-the-shelf exploits. An attacker spends days, weeks, or even months learning how an API behaves, how its endpoints relate, what sequence of ordinary-looking calls produces an extraordinary result, then automates the abuse. In a meaningful sense, each of these attacks is bespoke, which is why tools that work by matching traffic against signatures of known attacks tend to miss them entirely. The malicious sequence is made of individually valid requests.
Why is API security important?
By the end of 2025, half of the dynamic web traffic seen by Cloudflare was API-related, and that share keeps climbing. Most of it is automated, software talking to software, which is exactly the kind of traffic that hides abuse well. Each call is a request to do something or hand something over, and each is a potential target.
The industry saw this coming. In a 2017 report, Gartner predicted that by 2022, API abuse would become the most frequent attack vector behind data breaches for enterprise web applications. That was a forecast rather than a measured fact, but the years since have borne it out. When an API is compromised, attackers can reach the data and functionality behind it directly, stealing records, draining funds, or disrupting service. The fallout includes regulatory penalties under frameworks such as the GDPR and the CCPA, and eroded customer trust.
Two recent breaches show how ordinary the underlying mistakes tend to be. In January 2023, T-Mobile disclosed that an attacker had used a single API to pull data from roughly 37 million accounts. The extraction ran undetected from late November 2022 until early January 2023, about six weeks of valid-looking requests draining records before anyone noticed.
The Optus case is starker for being so basic. In September 2022, the Australian carrier exposed data on close to 10 million customers. The country's regulator later described the attack in a court filing as a simple trial and error. An endpoint sat on an internet-facing domain without requiring authentication, and that single oversight opened the door to the rest. The kinds of weakness behind both breaches each have a name on the industry's standard list of API risks.
The OWASP API Security Top 10
The common reference for what goes wrong with APIs is the OWASP API Security Top 10, maintained by the nonprofit Open Worldwide Application Security Project. The current edition was published in 2023 and replaced the original 2019 list. A few entries were renamed, two older ones (excessive data exposure and mass assignment) were merged into a single category, and newer concerns, such as unsafe consumption of third-party APIs, were added. One idea runs through nearly all of it: the client controls the request, and the server must never assume the request is honest.
API1. Broken object-level authorization. This is the most common and damaging API risk. It happens when an API checks that you are logged in but fails to verify that the specific item you are requesting actually belongs to you. APIs constantly identify things by an ID in the request, an order number, a user ID, or an account reference. If the server does not confirm that you are allowed to touch that particular object, you can change the ID and reach someone else's data. Consider an API that returns an invoice:
The request is properly authenticated, so a careless server returns invoice 4517. Nothing stops the user from asking next for 4518 and 4519, and onward, collecting invoices that belong to others. Sequential identifiers like these are what let the Optus attacker walk through an entire customer database.
API2. Broken authentication. Authentication is how an API verifies you are who you claim to be, and the endpoints that handle it (login, password reset, token issuance) are exposed to everyone, making them prime targets. An API is vulnerable when it permits weak passwords, allows unlimited guessing, or fails to validate the tokens it accepts. A frequent and underappreciated weakness in GraphQL is that a client can pack many operations into a single request. If an API limits login attempts to a few per minute but does not account for batching, an attacker can defeat that limit by sending dozens of guesses inside a single call:
To the rate limiter, this looks like a single request, but in reality, it contains many password attempts.
API3. Broken object-property-level authorization. While the first risk concerns reaching a whole object, this one concerns the individual fields within it. An API may return fields it should hide, or accept fields it should ignore. The second form, long known as mass assignment, is easy to picture. Suppose a video platform lets users edit a video's description through this request:
A user whose video was blocked replays the request and adds a field that the interface never offered:
If the server blindly maps incoming fields onto the stored object, the user just unblocked their own content by guessing a property name. The same trick can change a price, grant a role, or flip any internal flag that the developer assumed only the system controlled.
API4. Unrestricted resource consumption. Every request costs something: bandwidth, memory, processing time, and sometimes money, as when a call sends a text message through a paid provider. Without limits on how often or how heavily it can be called, an API can be driven offline or run up a large bill. A password-reset flow that sends a paid SMS on each attempt, fired tens of thousands of times by a script, costs real money in minutes.
API5. Broken function-level authorization. The cousin of the first risk: instead of another user's data, the attacker reaches another role's actions. It appears when an API fails to enforce that only certain users can perform certain operations, especially administrative ones. The telltale sign is whether an ordinary user can do something privileged simply by guessing the right endpoint or changing the request method, for instance, by calling an admin-only endpoint that creates an account with an administrator role.
API6. Unrestricted access to sensitive business flows. Some attacks exploit a feature that works exactly as designed, at a scale it was never meant to handle. A common case is scalping: a retailer releases a scarce, high-demand product, and an attacker scripts the purchase flow to buy the entire stock the moment it drops, then resells it at a markup. No endpoint is broken, no data leaks; the buy-a-product flow simply was not protected against bulk automation.
API7. Server-side request forgery (SSRF). This happens when an API fetches a resource from a web address the client supplies without checking where it points. Because the request comes from the server, it can reach internal systems that an outsider cannot. A feature that loads a profile picture from a URL, for example, can be pointed at an internal cloud-metadata address that returns the server's own access keys, the kind of credential exposure covered in secret scanning.
API8. Security misconfiguration. A broad category of settings and hardening that get overlooked: missing patches, unnecessary features left enabled, absent encryption, permissive cross-origin rules, and error messages that leak internal details. A memorable example is a class of attacks in which a crafted value in a request header is interpreted and executed by a vulnerable logging component on the server, turning an ordinary log entry into a remote code execution.
API9. Improper inventory management. You cannot protect what you don't know you have. This risk is about losing track of APIs and the data they touch: old versions left running, undocumented or forgotten endpoints, test and staging hosts exposed to the internet, and unclear records of which third parties receive your data. The Optus endpoint that leaked nearly 10 million records lived on a forgotten domain that stayed online after the fix reached only the main one. A security control placed in front of the current API is meaningless if an older copy of that API is still reachable elsewhere.
API10. Unsafe consumption of APIs. The final risk flips perspective to the APIs you consume rather than the ones you expose. Developers tend to trust data from a third-party service, especially a well-known one, more than they trust direct user input. If that service is compromised or simply behaves unexpectedly, the data it returns can carry an attack into your system. A service that blindly follows a redirect from a third party, for instance, can be steered into resending a user's sensitive data to an address the attacker controls.
Anatomy of an API attack
The ten risks rarely appear one at a time. A serious API breach usually chains several of them, each step ordinary on its own, into a result that is anything but. Walking through one invented but realistic example shows how the pieces fit, and why a defense that watches for known attack signatures tends to miss the whole thing.
Imagine an online store whose mobile application communicates with a backend via an API. An attacker starts with reconnaissance, the first phase of any real intrusion. By inspecting the app's traffic, they map the endpoints it calls and notice a naming pattern. Testing variations on it, they find an older endpoint, api.store.com/v1/, that still responds to requests long after the app moved to v2. Nobody is watching it, because nobody remembers it exists. That is improper inventory management (API9), and it is the foothold.
The attacker probes the forgotten endpoint and finds it never asks who they are. The authentication guarding the current version was added only in front of v2; the old copy was left open. Broken authentication (API2) means they can now call it freely, as any anonymous user.
Next, they study what the endpoint returns. A request for /v1/orders/10231 hands back another customer's order, complete with name, address, and the last digits of a card. The endpoint checks nothing about who owns order 10231. That is broken object-level authorization (API1), and the order numbers are sequential, so every record sits one digit away from the last.
The final step is automation. With no rate limit in place—unrestricted resource consumption (API4)—the attacker writes a short script that counts upward through the order numbers and pulls a record each time. Each request is individually valid, properly formed, and indistinguishable from a legitimate call. There is no malicious payload to detect, no known exploit string to flag. Over hours or days, the script quietly drains the database.
No single step here was sophisticated. The damage came from four small oversights lining up, the same shape as the Optus breach, and the same reason signature-based tools struggle: nothing in the sequence looks like an attack until you step back and see all of it at once.
API security best practices
Securing APIs is less a single product than a set of habits applied continuously, from the first design sketch to the day an API is retired. The practices below address the risks above without treating any one of them in isolation.
Know what you have, because you cannot defend an endpoint you have forgotten. Keep a current inventory of every API, host, and version; actively discover shadow, deprecated, and third-party APIs; retire old versions on purpose; and keep real customer data out of test and staging environments.
Enforce authentication and authorization on every request. Confirm who is calling, and separately confirm what they may do, checking permission for the specific object and the specific function before acting. Deny access by default, grant the least privilege needed, validate every token, add multi-factor authentication where you can, and rely on proven standards rather than homemade schemes.
Validate input and limit consumption. Treat every request as untrusted, accept only the fields and formats you expect, and reject the rest. Apply rate limits and quotas, cap the size and number of operations per request, and set spending alerts for any paid third-party service that a call can trigger.
Encrypt data in transit. Send all API traffic over TLS, the protocol behind HTTPS, for internal calls as well as public ones, so that intercepted traffic reveals nothing.
Distrust the APIs you consume. Validate and sanitize data from third-party services as strictly as user input, restrict where your API may send requests, and never follow redirects to unverified destinations.
Build security in and test continuously. Bring security into design reviews, including the business logic attackers probe, and apply security patches as soon as they are disclosed. Combine automated scanning and fuzzing, which quickly catch known flaws and edge cases, with manual penetration testing, which finds the logic and access-control flaws that tools cannot. Log and monitor activity to shorten the window in which abuse goes unseen, and retest after each fix to confirm it holds.
Fluid Attacks helps you secure APIs
At Fluid Attacks, we secure APIs and microservices as part of a continuous, comprehensive approach to application security across the development lifecycle. We pair automated scanning with the manual work of certified pentesters, including penetration testing, secure code review, and reverse engineering, to catch the business-logic flaws that tools alone miss, all on a single platform with minimal false positives and clear remediation guidance. Start a free trial to begin testing your APIs today.
