The hidden costs of ignoring API security are mostly not the breach headline. They are surprise usage bills, fraud through legitimate-looking calls, hours lost finding which APIs exist, audit findings and slow incident response. Several appear on OWASP's 2023 API list as risks, not just as bugs.
Why do APIs hide costs?
An API is a front door with no visible door. It answers requests from anyone who can form them, at whatever speed they can send them. Most of the cost comes from what the API allows a caller to do, rather than from a clever exploit.
We are not quoting breach cost averages in this post. We have not fetched a primary source for a current figure, and an unsourced number would mislead. The costs below can be reasoned about from OWASP's own descriptions.
Where do the costs show up?
Resource bills. OWASP lists "Unrestricted Resource Consumption" as API4:2023. Its description says successful attacks can lead to denial of service or "an increase of operational costs", and notes that some resources, such as emails, SMS or phone calls, are paid for per request. An endpoint that sends a text message on every call, with no limit, is a billing line an attacker can run up.
Abuse of business flows. API6:2023, "Unrestricted Access to Sensitive Business Flows", is about functions like buying a ticket or posting a comment used in bulk by automation. There may be no bug at all. The cost is stock hoarded by bots, spam, or promotion codes drained.
Data exposure. API1:2023, "Broken Object Level Authorization", and API3, "Broken Object Property Level Authorization", cover one user reaching another's records, or fields they should not see. The cost is notification, legal review and customer trust.
Server side request forgery. API7:2023 describes an API that fetches a user-supplied address without validating it. In cloud settings that can reach internal services.
Unknown APIs. OWASP's list also includes improper inventory management. If you cannot list your APIs and versions, you cannot patch or retire them. Old versions linger with weaker checks.
People time. During an incident, the first question is "which API served that request, and who owns it?" Without an inventory and logs, answering takes days.
What does a constructed case look like?
A ride-sharing startup exposes a "send verification code" endpoint. It has no per-number or per-IP limit. A script calls it a hundred thousand times with fake numbers. The firm pays its SMS provider for every message and learns about it from the invoice. No data leaked, and the cost was real.
How do you make the case internally?
Finance teams respond to costs they can see. Pull the last three months of bills for paid API-triggered services, such as SMS, email and mapping, and plot daily volume. Spikes with no matching business event are your evidence. Pair that with the inventory work: the number of APIs nobody can name an owner for is a risk figure everyone understands. Put the two on one page, and ask for time to add limits and ownership. It is easier to fund a fix described in terms of money lost than a score on a scanner.
How to check or apply this
- Build an inventory: every API, version, owner and whether it is public. Include old versions.
- For each endpoint that calls a paid service, set rate limits and a spending alert.
- Test object-level authorization on every endpoint that takes an ID. Try another user's ID with your own token.
- Mark business flows that could be abused in bulk, and add limits or friction there.
- Validate any user-supplied URL before the server fetches it.
- Log requests with caller identity, and keep logs long enough to answer incident questions.
- Retire old API versions on a schedule.
Quick check
Is API security only about stopping hackers?
No. Several OWASP API risks involve legitimate use at abusive scale, which costs money without any exploit.
Where should a team start?
With an inventory. You cannot protect, limit or retire an API you do not know exists.
Sources
Last reviewed: 18 October 2026.
