An application programming interface, or API, lets software request data or trigger actions in another service. When a banking app displays a balance, an online store retrieves an order, or an AI assistant calls a search tool, an API often carries the request. That makes APIs useful building blocks for modern software. It also makes them attractive targets: the same interface that efficiently serves legitimate clients can efficiently serve an attacker if the rules behind it are weak.
An API attack does not always require breaking into a server. An attacker may use a normal account, inspect the requests made by a browser or mobile app, and ask the server for a different customer's record. Another may steal a token and use it as its rightful owner would. A third may repeatedly call a legitimate lookup function until a modest information leak becomes a large data set. The security question is therefore deeper than whether an endpoint is reachable: what should this caller be allowed to do, with which data, how often, and through which chain of connected services?
How APIs work, and why attackers target them
Most web and mobile interfaces are clients of an API. A client sends a request to an endpoint, such as GET /orders/1842, and the server returns a structured response, often JSON. The request might carry a session cookie, an access token or an API key. The server may then query a database, call another internal service or use an external provider. Cloud applications, microservices and AI agents add more of these machine-to-machine exchanges, sometimes without a visible user interface at all.
This structure gives attackers a clear map to probe. Endpoints have names, parameters, identifiers and predictable responses. Browser developer tools can show what a web app requests; a mobile client likewise has to communicate with its backend. Hiding a button in the interface does not remove the underlying route, and concealing an API key in client-side code cannot make that key secret. The server must make its own decision about each request. The OWASP API Security Top 10 (2023) provides a useful map of the recurring weaknesses behind those decisions.
That decision has several layers. Authentication asks who the caller is. Authorization asks whether the caller can perform this operation on this resource. A third question concerns the fields within the resource: an account holder may be allowed to see a profile while being barred from viewing an internal fraud flag or changing an administrative role. Finally, an operation can be permitted in isolation but harmful at scale. A contact-discovery feature may work as designed for one user yet become a tool for enumeration when invoked across millions of inputs.
The scope of an API is also easy to underestimate. Public endpoints coexist with partner integrations, internal services, old versions and test deployments. A developer may protect the newest mobile route while an older route still exposes the same records. An AI agent with access to calendars, files or billing tools adds another caller whose effective permissions depend on the tool's credentials and the checks made by the service receiving each call. The technology changes, but the trust boundary remains the same: every request crossing into a service needs a defensible access decision.
The main ways API attacks work
Changing an object identifier. Consider an authenticated customer who can retrieve GET /orders/1842. If changing 1842 to 1843 returns another customer's order, the endpoint has a broken object-level authorization problem, often called BOLA or IDOR. The attacker has passed authentication; the failure is that the server trusts an identifier supplied by the client without checking ownership or other access policy. The same error can affect PATCH and DELETE routes, turning disclosure into modification or destruction. Unpredictable identifiers make guessing harder, but they do not replace a server-side permission check. OWASP's BOLA guidance stresses checking access wherever client input identifies a record.
A simplified request flow shows where the two implementations diverge:
PROTECTED API
User A → GET /orders/1843
↓
Server checks owner: User B
↓
403 Forbidden
VULNERABLE API
User A → GET /orders/1843
↓
No ownership check
↓
200 OK: User B's orderCrossing role or field boundaries. A regular user may discover an administrative endpoint and call it directly, exposing a function-level authorization gap. Alternatively, an API may return a complete database object when the interface needs only a name and status. Sensitive fields can appear in the raw response even if the web page never displays them. An update endpoint can have the inverse problem: automatically mapping every submitted JSON property into a stored object may let a user set a field such as role or creditLimit. OWASP groups excess exposure and unauthorized modification under broken object-property authorization. Explicit response and update schemas help define which fields are allowed in each operation.
Abusing credentials and tokens. A password, API key or bearer token can be copied from a repository, log, browser archive or compromised device. If the service accepts that credential, the request may appear legitimate even when the person sending it is an attacker. Flawed token validation, long-lived credentials and broad permissions increase the damage. An API key can identify an application or meter usage, but it does not by itself establish which end user may read a particular record. Short-lived tokens, narrow scopes, secure storage, revocation and careful logging reduce exposure; resource-level authorization is still required after the token is validated. OWASP's REST guidance makes that distinction clear. For a broader view of how identity-based attacks fit into the threat landscape, see Meta News's coverage of the Talos year in review.
Automating a legitimate flow. Attackers can repeatedly call search, account recovery, contact matching or purchase endpoints. They may enumerate accounts, scrape information, exhaust a scarce item or consume compute and paid third-party services. A single request can look ordinary, so defenses must consider the behavior across requests. Per-user and per-operation limits, pagination caps, cost budgets and alerts can constrain abuse. Those controls need to account for distributed activity across many accounts or devices, and they should never be treated as a substitute for access control. OWASP describes both unrestricted resource consumption and abuse of sensitive business flows in its API risk list. AI API draining is one example of how unauthorized usage can become a financial security problem.
Trusting another service too much. An API that accepts a URL and fetches it on behalf of a user can be exposed to server-side request forgery if the destination is not constrained. A service that imports data from a partner API may also trust the returned content more than it trusts direct user input. In both cases, the attack crosses an integration boundary: the receiving application still has to validate destinations, data and permissions. This matters for AI systems that call tools or retrieve external content, where a model's instruction to use a tool should never grant more authority than the underlying user and service are entitled to exercise.
What real incidents teach us
Case study — T-Mobile, 2023. In a filing with the US Securities and Exchange Commission, the company said it had identified an actor obtaining data through a single API without authorization. Its preliminary investigation put the affected population at approximately 37 million current customer accounts. The accessible data included names, contact details, dates of birth and account information; T-Mobile said the API did not provide passwords, payment-card data or government identification numbers. The filing did not establish whether BOLA, stolen credentials, an overly permissive endpoint or another mechanism caused the exposure. The defensible lesson is about concentration: one data-bearing interface can create substantial reach even without evidence of a broader network compromise.
Case study — Facebook's contact importer. Meta said that malicious actors used the feature before September 2019 to match uploaded phone numbers to profiles and scrape information. Data associated with more than 530 million users later circulated publicly. Meta described this as scraping rather than a hack of its systems, and said it changed the feature to block software that imitated its app and submitted large sets of numbers. The case shows why an endpoint can be risky even when its individual requests follow the expected workflow. The surrounding limits and detection determine whether the workflow can be turned into bulk collection.
Neither incident should be flattened into a generic claim that all API exposures arise from the same bug. The public record for T-Mobile does not reveal the exact technical path. The Facebook case is specifically about automated misuse of a matching function. Together they make a broader point: API security has to cover both who may access a record and how an allowed function behaves at scale.
How organizations can reduce exposure
Start by knowing what exists. Maintain an inventory of public, partner and internal APIs, their owners, versions, data types and intended callers. Include endpoints in old deployments and integrations that bypass the main application gateway. An API that nobody remembers is unlikely to receive consistent policy checks, logging or retirement. Keep the inventory tied to code and deployment changes so that a new route cannot silently become part of the production attack surface.
Next, put authorization in the service's request path. For each operation, evaluate the authenticated principal, the requested action, the resource and any sensitive fields. Default to denying access when the policy is unclear. A shared authorization layer can make decisions consistent, but the application still needs the context to distinguish a user's own invoice from another tenant's invoice. Test both horizontal access, between peer accounts, and vertical access, between ordinary and privileged roles. Repeat those tests for reads, updates and deletes; passing one method says little about another.
Treat credentials as limited grants rather than permanent master keys. Store secrets outside source code and client bundles, protect them in logs and support files, and give services only the scopes they need. Prefer short-lived credentials where practical, rotate exposed ones promptly and keep a path to revoke them. Encrypt traffic with HTTPS. For high-value operations, record which user and service initiated the action so that a shared integration token does not erase accountability. Authentication controls reduce impersonation, while authorization still determines what an authenticated caller may do.
Constrain data and workload deliberately. Return only the fields required by the client; allow updates only to explicitly approved properties. Validate input sizes, response sizes and pagination. Apply limits at several levels, including account, endpoint and expensive downstream operation, and alert on unusual access to many distinct records. A sudden run of successful 200 responses can be more revealing than a spike in errors if it indicates bulk collection. For services that invoke paid APIs or AI models, add budgets and usage visibility because abuse may first appear as a bill rather than an outage.
Finally, test the system as an attacker would, within an authorized environment. Use separate test accounts and tenants, exchange object identifiers, compare role permissions, inspect raw responses and check what happens when a client sends unexpected fields. Add these cases to automated tests so that a later feature change does not reintroduce the same weakness. Review third-party data and URL-fetching integrations, and make sure incident responders can trace a suspicious token, route and sequence of requests quickly. A gateway or web application firewall can help with traffic control and visibility, but only the application has enough context to decide whether this caller should see this particular record.
APIs will continue to connect browsers, mobile apps, cloud services and AI tools. Their security depends less on obscuring the interface than on enforcing precise rules behind it. When an organization knows its endpoints, limits each caller's authority, watches for abuse and tests those assumptions continuously, an API can remain useful without becoming an easy route to everyone else's data.
Frequently asked questions
What is an API attack?
An API attack is an attempt to use an application's programming interface to access data, perform an unauthorized action or abuse a permitted operation. It may exploit a coding flaw, stolen credentials or the way a legitimate feature behaves at scale.
Can hackers exploit an API without authentication?
Yes. Public or mistakenly exposed endpoints can be abused without a login. Attackers can also use valid accounts or stolen tokens against authenticated APIs; being signed in does not mean a caller is authorized to access every record.
What is the difference between BOLA and IDOR?
IDOR describes access to an object through a user-controlled reference without an adequate permission check. BOLA is the API-focused name for this kind of broken object-level authorization; the terms overlap, although BOLA emphasizes the missing policy check at an API endpoint.
How can developers prevent API vulnerabilities?
Inventory endpoints, enforce authorization for every operation and object, validate allowed fields, and restrict credentials to the minimum necessary scope. Add tests across users and roles, limit expensive or enumerable requests, and monitor for unusual patterns of successful access.