Roughly 83 percent of internet traffic now runs through APIs. Most security budgets still go toward the website sitting on top of them, not the APIs actually moving the data.
Most businesses can tell you exactly how their website is protected, a firewall in front, a scan run every quarter, maybe a penetration test once a year. Ask the same business how many APIs they actually have running, and the answer is very often a guess. Not an approximate number. A guess, followed by a slightly uncomfortable pause.
That gap matters more than it used to. Roughly 83 percent of all internet traffic now moves through APIs, not the websites and apps people actually see. Akamai’s most recent threat report found that 87 percent of organizations were hit by API attacks in the past year, and APIs now account for 43 percent of the vulnerabilities actively being exploited according to CISA. Attackers have quietly shifted their attention to exactly the part of the business nobody is watching as closely.
This post breaks down why APIs became the preferred target, what a shadow API actually is, and what it would take to know your own exposure honestly.
What an API Actually Is, in Plain Terms
An API, application programming interface, is how different pieces of software talk to each other without a human in between. When a mobile banking app shows your balance, it is not storing that number itself, it is asking an API for it, in real time, every time you open the app. Every modern app, every integration between two systems, every “connect your account” button, runs on an API doing that handoff behind the scenes.
Why APIs Carry Almost All Your Traffic Now
A decade ago, most business risk sat squarely on the website, the thing customers actually typed into a browser. That has changed completely. Mobile apps, partner integrations, internal tools, and increasingly AI systems all talk to each other through APIs rather than a browser, which is exactly why the traffic split has flipped so dramatically toward APIs and away from traditional web pages.
The Shadow API Problem: You Don’t Even Know They’re All There
A shadow API is one that exists and is actively running, but was never documented, approved, or added to any official inventory, often built quickly by a developer to solve an immediate problem and never formally tracked afterward. Security audits consistently find that shadow and forgotten APIs make up somewhere between 30 and 40 percent of an organization’s actual API footprint, and only around 15 percent of organizations report strong confidence in knowing their full API inventory. That means, for most businesses, close to a third of their own attack surface is effectively invisible to their own security team.
Zombie APIs: The Old Version Nobody Turned Off
Related but distinct from shadow APIs, a zombie API is one that used to be officially supported and known, but was replaced by a newer version and simply never switched off. The old endpoint keeps running, often with weaker security than whatever replaced it, quietly reachable by anyone who still knows, or guesses, the address. This is more common than most businesses assume, since decommissioning old infrastructure is rarely anyone’s top priority once a replacement has shipped.
Why APIs Get Less Scrutiny Than Websites
This is not negligence so much as history. Security tooling, testing processes, and even most people’s mental model of “our application” were built around websites first. APIs often get added later, by developers moving quickly to ship a feature, without the same review cycle a customer facing page would automatically go through. The result is a form of attention gap, real, but based on habit rather than deliberate risk decisions.
BOLA: The Same Access Control Flaw, Now at API Scale
Broken Object Level Authorization, BOLA, sits at the very top of OWASP’s dedicated API Security list, and it describes essentially the same access control failure we covered in a recent post about IDOR vulnerabilities, an API returning data based on an identifier without properly checking whether the requester is actually authorized to have it. At API scale, this is often worse, not better, because APIs are frequently called automatically, at high volume, by other software, giving an attacker who finds the flaw a much faster way to extract large amounts of data than clicking through a website ever would.
59 Percent of API Vulnerabilities Need No Authentication At All
This is one of the more unsettling figures in current API security research. Well over half of documented API vulnerabilities do not require an attacker to log in, authenticate, or bypass any credential check whatsoever, the flaw is reachable by anyone who simply knows or guesses the endpoint exists. Combined with the shadow API problem, this describes a meaningful share of many businesses’ real exposure sitting completely open, not behind a broken lock, but behind no lock at all.
Why this matters
A website with no login page would alarm anyone immediately. An API with no authentication check often looks, from the outside, exactly like one that’s working correctly.
Rate Limiting: Why Nothing Stops an Attacker From Just Asking a Million Times
Rate limiting caps how many requests a single source can make in a given window. Without it, an API will often simply keep answering, as fast as it is asked, whether that’s a legitimate customer or an automated script attempting to guess account numbers, enumerate data, or brute force a login thousands of times a minute. Missing rate limiting is a factor in a significant share of documented API abuse cases, and it is one of the simpler gaps to close once it is actually identified.
Business Logic Abuse: When Attackers Don’t Break Anything, They Just Misuse It
Some of the most damaging API attacks involve no technical exploit at all. Business logic abuse means using a feature exactly as it was built, just in a way nobody anticipated, repeatedly applying a promo code meant for one use, manipulating a pricing calculation through a sequence of legitimate calls, or automating a password reset flow to enumerate valid accounts. Because nothing is technically broken, these patterns are often the hardest for automated tools to catch at all.
How AI Generated Code Is Making This Worse, Not Better
As more API code gets written with AI assistance, a new pattern is emerging, AI generated endpoints that function correctly but skip security fundamentals, proper authentication, input validation, rate limiting, because the tool was optimized to produce working code quickly, not necessarily secure code by default. Security researchers are increasingly recommending that AI generated APIs receive extra scrutiny specifically because of this gap, treating speed of development as a new source of risk rather than purely a productivity win.
Not sure how many APIs your business actually has running?
Book a free security assessment and Ambsan’s team will help you find out.
Third Party APIs: The Risk You Didn’t Build But Still Own
Most modern applications connect to external APIs, payment processors, analytics platforms, messaging services, without building any of that functionality themselves. When one of those third party services gets compromised or misconfigured, the risk flows directly into any business relying on it, regardless of how well that business secured its own code. This mirrors the supply chain risk we covered in our OWASP Top 10 breakdown, and it applies just as directly to APIs as it does to code libraries.
A Real Example: What Happens When an API Gets Breached
In 2023, a major telecom provider disclosed a breach traced to a single API that exposed the personal data of over 37 million customers, driven by an authentication failure on that endpoint. A separate incident affecting a large telecom operator exposed close to 10 million user records, nearly 40 percent of that country’s population, through similar API related weaknesses. Neither incident required attackers to breach a website’s front door. Both went in through the API layer sitting behind it.
Why Traditional Web App Testing Misses APIs
A penetration test scoped only against a website’s visible pages will often never touch the APIs that page quietly calls in the background, especially internal APIs, partner integrations, or endpoints used only by a mobile app rather than the browser. This is exactly why scope matters enormously when commissioning any kind of security testing, a test that never looks at your APIs is a test that never looked at 83 percent of your actual traffic.
The Discovery Problem: You Can’t Secure What You Can’t See
Every other issue in this post assumes a business at least knows an API exists in order to secure it. Given that shadow and zombie APIs commonly make up close to a third of a real environment, discovery has to come first, actively finding every endpoint currently running, through traffic analysis, code review, and infrastructure audits, rather than relying on whatever list of APIs someone remembers to keep updated.
What Proper API Security Actually Looks Like
- A current, actively maintained inventory of every API in production, not a document nobody has opened in a year
- Authentication and authorization enforced on every endpoint, tested specifically for BOLA style access control flaws
- Rate limiting applied consistently, not just on the endpoints someone happened to remember
- Regular testing that explicitly includes APIs, not just the customer facing website sitting in front of them
- A defined process for retiring old API versions completely, rather than leaving them reachable indefinitely
Checklist: Do You Actually Know Your Own API Footprint
- Could your team produce a complete, current list of every API in production right now, without guessing
- Has your most recent security test explicitly included your APIs, not just your website
- Do you know whether any API endpoints require zero authentication to reach
- Is there a documented process for retiring old API versions when a new one replaces them
- Have your third party API integrations, payment, analytics, messaging, ever actually been reviewed
How Ambsan Tests APIs as Part of Application Security and VAPT
Ambsan’s Application Security and VAPT services explicitly scope APIs into testing, not as an afterthought, but as a primary target given how much real business traffic now flows through them. That includes testing for BOLA and other access control flaws, checking authentication and rate limiting enforcement, and helping businesses build the kind of API inventory that makes ongoing security actually possible rather than a one time snapshot.
This connects directly to the broader application security work covered in our recent breakdowns of the OWASP Top 10 and IDOR vulnerabilities, since APIs are increasingly where both of those risks actually live in practice.
Find out what’s actually running in your API layer
Ambsan’s team helps you discover, inventory, and test the APIs your business depends on, including the ones nobody remembers building.
Book a Free Security Assessment Explore VAPT Services
Frequently Asked Questions
What is a shadow API?
A shadow API is an active, running API endpoint that was never documented, approved, or added to an organization’s official inventory, often created quickly by a developer and never formally tracked, leaving it invisible to the security team responsible for protecting it.
What is the difference between a shadow API and a zombie API?
A shadow API was never officially documented in the first place. A zombie API was once known and supported, but was replaced by a newer version and never actually shut down, leaving the old endpoint reachable and often less secure than its replacement.
What percentage of internet traffic goes through APIs?
Recent industry estimates put API traffic at roughly 83 percent of total internet traffic, reflecting how much modern software relies on APIs rather than traditional browser based interactions.
What is BOLA in API security?
Broken Object Level Authorization, BOLA, is the top ranked risk in OWASP’s API Security list. It occurs when an API returns data based on a supplied identifier without properly verifying that the requester is authorized to access that specific data.
Do APIs need authentication for every request?
Yes, ideally. Research indicates a majority of documented API vulnerabilities require no authentication at all to exploit, meaning the endpoint is reachable by anyone who knows or guesses it exists, without any credential check in place.
Why don’t automated scanners catch all API vulnerabilities?
Many API risks, particularly business logic abuse and access control flaws like BOLA, do not produce a technical error an automated scanner can detect. They require understanding whether a specific response should be allowed for a specific user, which typically requires manual testing.
Can a business be breached through an API even if its website is secure?
Yes. Several major real world breaches, including incidents affecting tens of millions of customer records, occurred through API vulnerabilities without any compromise of the associated website’s front end at all.
How does AI generated code affect API security?
AI generated API code can function correctly while skipping security fundamentals like proper authentication, input validation, and rate limiting, since these tools are often optimized primarily for producing working code quickly rather than secure code by default.
How can a business find out how many APIs it actually has?
Proper discovery typically involves traffic analysis, source code review, and infrastructure audits rather than relying on an internal list, since shadow and zombie APIs commonly make up a significant share of an organization’s real API footprint.
Final Thoughts
The shift toward APIs did not happen because anyone decided to deprioritize security there. It happened because software architecture changed faster than most security programs adapted to follow it. The result is a genuine, measurable gap, the majority of real traffic now moves through the part of the business that gets the least testing, the least documentation, and the least attention.
Closing that gap does not require abandoning everything already in place for your website. It requires accepting that your APIs are not a background detail anymore. For most businesses today, they are the business.
Related: The 10 Ways Your Web App Is Most Likely to Get Hacked in 2026
Related: The Data Breach That Needs Zero Hacking Skills
Related: Black Box vs White Box vs Grey Box Penetration Testing, Which One Does Your Business Actually Need
Ready to find out what’s really in your API layer?
Book a free, no obligation consultation with Ambsan’s team and get a clear picture of your real API exposure.
Schedule a Consultation
See All Services
Ambsan Technologies is a Karachi based cybersecurity firm serving businesses across Pakistan and the United States, offering application security, VAPT, and managed IT services for SMEs and enterprises.