Related: how to become an AppSec engineer, OWASP Top 10 explained, a startup API audit, GraphQL security testing, mentoring.
APIs became the main target for attackers a long time ago. Not because they are especially weak, but because there are too many of them and nobody really watches most of them. Every service, mobile app, and partner integration adds another dozen endpoints that only git history remembers six months later.
The numbers back this up. According to Wallarm, the number of API vulnerabilities grew by 21% in Q2–Q3 2024 alone. A third of them (32%) sit in clouds and cloud-native applications. The worst part: most of these vulnerabilities score CVSS 7.5 or higher, which means critical issues, not minor ones.
I went through the Dark Reading piece on this topic and pulled out the four root causes that actually get companies breached. Under each one: what teams do wrong and how to fix it.
Why APIs became the main target
The Imperva State of API Security report shows the scale of the problem. API traffic already makes up 71% of all web traffic. An average company makes about 1.5 billion API calls per year and runs an average of 613 endpoints per account. At that volume an attacker does not need a sophisticated vector: one forgotten endpoint without authorization is enough.
Nick Rago, Field CTO at Salt Security, puts it bluntly: in the vast majority of incidents the barrier to entry was very low, and the attacker did not have to make any heroic effort. This is the key idea of the whole article: companies get breached not through genius exploits, but through basic things nobody checked.
Hole 1: misconfigured APIs
This is the number one cause of every major leak in recent years, and also the most embarrassing one. The API works, the business is happy, but the configuration leaves doors open that anyone can find with simple enumeration.
The typical set of mistakes looks like this:
- No object-level authorization checks (BOLA/IDOR). You request
/invoices/123— that is your invoice. You change it to/invoices/124— someone else's, and the API happily returns it. - No real authentication. The endpoint was simply left open: it used to be internal, then became external, and nobody ever added a token check.
- No rate limiting. IDs, logins, and confirmation codes can be brute-forced without a pause — the server never pushes back.
- Internals leaking in error messages. Stack traces, SQL queries, and internal IP addresses right in the response body — a ready-made map for the attacker.
How to fix it. Check permissions on every object, not just at the API entry point: an authenticated user is not automatically the owner of a specific resource. Use Role-Based Access Control and MFA for sensitive operations. Filter responses on the server and never return fields the client does not need. And put rate limiting everywhere there is an ID, a login, or a search.
Hole 2: badly designed APIs
This is no longer a configuration mistake but a thinking mistake. The API does exactly what it was designed to do, but it was designed in a way that invites abuse. Formally everything works, the tests are green, and the hole is architectural.
Classic examples from practice:
- The API returns more data than the interface needs. The client app shows three fields, the response contains thirty — and someone can scrape your database for years with perfectly legal requests.
- An endpoint accepts unvalidated input or exposes implementation details that make the next attack easy to build.
- Business logic is not protected at all: you can change the price of an item in the cart, apply two incompatible coupons, or send
amount=-1000and receive money instead of paying.
Business logic abuse is exactly the main trend of recent years. According to the Imperva State of API Security 2024 report, such attacks made up 27% of all API attacks in 2023, up 10% year over year. A scanner cannot find these issues in principle: from the protocol's point of view the request is completely valid.
Salt Security offers a precise comparison: a badly designed API is like building a hospital without blueprints and then being surprised that patients fall down the elevator shaft. This is not fixed with a patch but with a process: think about security at the design stage, not after release, and add behavioral threat protection that can tell anomalous usage from normal.
Hole 3: lack of visibility
Back to that Imperva number: an average of 613 endpoints per account. Now the honest question: who in the company knows all of them? In practice — nobody. There is no inventory, and the OpenAPI spec describes, at best, what the team happens to remember.
This is where shadow APIs come from — endpoints that exist in no documentation at all. Old v1 versions that nobody switched off after the v2 release. Beta endpoints shipped without authentication "for a week, just for testing." Internal utility routes exposed to the internet because it was faster that way.
The most famous example is the Optus breach in Australia: data on 9.7 million customers leaked through an undocumented endpoint with no authorization. It was not listed in any OpenAPI spec, so nobody ever tested it. Kimm Yeo of Black Duck explains why this is a systemic problem: today's solutions discover APIs only in production, and when a critical alert comes in, it is impossible to trace it back to the code.
What to do. Keep an inventory of all external APIs, not only the ones that made it into Swagger. Hunt for your own endpoints the way an attacker would: scan JS bundles, subdomains, and Shodan. And do it before production, at the development stage, not after the first incident.
Hole 4: inadequate security testing
According to a Postman survey, only 37% of organizations have formally built security testing into the API lifecycle. The same 37% run automated scans and regular pentests. The remaining two-thirds of the market are essentially hoping to get lucky.
The teams that get it right follow a spec-first approach. First the API blueprint in OpenAPI/Swagger, then an architecture sign-off with security at the table, and only then the code. Salt Security continues the analogy: you need to draw the hospital first and check the construction against the plan before letting patients in. It sounds obvious, but in most companies the process still works the other way around.
If you want to learn to run these checks by hand — intercepting traffic, swapping IDs, working with tokens, and writing a clear report — I covered that path in detail in how to become an Application Security Engineer. A real example of a full assessment cycle is in the startup API audit breakdown.
Bottom line: two outcomes and a baseline
Whatever the specific vulnerability, every API risk comes down to two outcomes. First: someone got access to something they never should have seen. Second: someone took your API down and the business stopped. Everything else is a variation.
Defense against both outcomes starts with a baseline that, frankly, almost nobody maintains:
- Know all of your APIs, including old versions and forgotten beta endpoints.
- Know which of them require authorization, and verify it regularly, not once at release.
- Check permissions on the server, not the client: a hidden button in the UI is not access control.
- Put proper rate limiting everywhere something can be enumerated.
Original piece: Dark Reading, November 1, 2024, by Jai Vijayan. Numbers are from the Wallarm report, Imperva State of API Security 2024, and the Postman survey.
Training and contact
If you need systematic hands-on practice in API security — access control, working with tokens, hunting shadow endpoints, and professional reports — see the program on the Application Security Engineer page.
You can put together an individual preparation plan for your background on WhatsApp. The format of working together is described in detail in the cybersecurity mentoring section.
Also: how to become an AppSec engineer, OWASP Top 10 explained, a startup API audit, GraphQL security testing, mentoring.
I teach AppSec in practice: access control, APIs, reports, interview prep. Need a plan for your background? Message me on WhatsApp.
