Not long ago, the conversation around application security was mostly about web interfaces — login pages, input fields, session handling. The assumption was simple: if a user can interact with it through a browser, that is where the risk lives.
That assumption is now dangerously outdated.
Today, APIs — Application Programming Interfaces — are the backbone of nearly every digital product. Your mobile app talks to your backend through an API. Your payment provider connects via an API. Your internal tools share data through APIs. Your SaaS integrations run on APIs. And every single one of those connections is a potential entry point for an attacker.
APIs now account for the majority of web traffic globally — and the majority of security incidents that organisations fail to detect until significant damage has already been done.
This is not a theoretical risk. It is a practical one that we encounter in almost every assessment we conduct. And it is one that a large number of organisations are significantly underprepared for.
Why APIs Create a Fundamentally Different Risk Profile
When you secure a web application, you are dealing with a defined interface. There are pages, forms, buttons — things a user can see and interact with. Security controls like web application firewalls, rate limiting, and input validation are relatively straightforward to apply because the surface is visible.
APIs work differently. They are designed to be consumed by machines, not humans. They expose functionality and data directly — often without the layers of presentation logic that slow down or complicate attacks on traditional web applications. An attacker with access to your API endpoints can, in some cases, do more damage more quickly than someone attacking your front-end interface.
There are three characteristics that make APIs particularly challenging to secure:
They multiply rapidly. A typical enterprise today has hundreds or even thousands of API endpoints. New ones are added constantly — by development teams, third-party integrations, and internal tools. Many organisations do not have a complete, up-to-date inventory of their own APIs. You cannot protect what you do not know exists.
They expose business logic directly. Unlike a web interface that controls what actions a user can take through the UI, an API often exposes the underlying business logic more directly. This means that logic flaws — errors in how the application decides what a user is allowed to do — are both more common and more exploitable.
They are often insufficiently tested. Traditional penetration testing and vulnerability scanning evolved around web interfaces. Many organisations apply these same approaches to APIs and assume the coverage is equivalent. It is not. APIs require specific testing methodologies, particularly around authentication, authorisation, and business logic — areas where automated scanners frequently miss critical vulnerabilities.
The Most Common API Vulnerabilities We Find in Practice
The OWASP API Security Top 10 is the closest thing the industry has to a definitive list of API-specific risks. But rather than simply repeat that list, it is more useful to talk about what we actually find when we conduct API security assessments — and why these issues keep appearing even in organisations that consider themselves security-conscious.
Broken Object Level Authorisation (BOLA)
This is consistently the most common and impactful finding. An API endpoint accepts a resource identifier — a user ID, order number, or document reference — and returns data without properly verifying that the requesting user is actually authorised to access that specific object. Change the ID in the request, get someone else's data. Simple to exploit, often hard to detect, and present in a surprising number of production systems.
Broken Function Level Authorisation
Administrative or privileged functions exposed through API endpoints without adequate access controls. In practice, this often means an endpoint intended only for admin users is accessible to any authenticated user — sometimes even unauthenticated users — simply because the developer assumed the front-end would restrict access.
Excessive Data Exposure
APIs returning far more data than the consuming application actually needs — and relying on the client to filter what gets displayed. This means sensitive fields are being transmitted even when they are not shown in the UI. An attacker intercepting or directly calling the API gets everything in the response, not just what the interface shows.
Lack of Rate Limiting and Resource Controls
APIs without proper rate limiting are vulnerable to enumeration attacks, credential stuffing, and automated scraping. We regularly find endpoints that will happily accept thousands of requests per minute — making it trivial to iterate through user IDs, test stolen credential lists, or extract entire datasets.
Security Misconfiguration
Default credentials left on API management platforms, verbose error messages exposing internal stack traces, CORS policies set too permissively, outdated TLS configurations, and debug endpoints left accessible in production. These are not sophisticated attacks — they are straightforward misconfigurations that are consistently present and consistently exploited.
A Pattern Worth Understanding: The Invisible API Problem
One pattern we encounter repeatedly deserves special attention because it is both common and underappreciated. We call it the invisible API problem.
As organisations grow and development teams expand, APIs accumulate. Old versions are never fully decommissioned — they continue running in production long after the team that built them has moved on. Microservices proliferate, each exposing its own API surface. Shadow IT introduces third-party integrations that create undocumented API connections between internal systems and external services.
The result is an API landscape that nobody has a complete map of. Security teams are trying to protect something they cannot fully see, and development teams are building on top of foundations they do not fully understand.
Before you can assess the security of your APIs, you need to know what APIs you have. API discovery — building a complete, current inventory of every endpoint across your environment — is often the most valuable first step of any API security engagement.
It is also frequently the step that reveals the most surprises.
Where to Start: A Practical Approach
If you are a security-aware developer, engineering lead, or CISO looking at your API security posture and wondering where to begin, here is a practical framework based on what we recommend to our clients:
Start with visibility
Build or obtain a complete inventory of your APIs. This includes internal APIs, external-facing APIs, third-party integrations, and any legacy or versioned endpoints still running in your environment. You cannot prioritise what you cannot see.
Assess your authorisation logic
BOLA and broken function-level authorisation are your highest-priority risks. Review how your APIs verify not just that a user is authenticated, but that they are specifically authorised to access the object or function they are requesting. These checks need to happen server-side, every time, without exception.
Review what your APIs expose
For each endpoint, ask: what data does this response return, and does it return anything that the consumer does not actually need? Apply the principle of least privilege to data exposure — return only what is required, and filter server-side rather than relying on the client to handle it.
Implement rate limiting and monitoring
Every API endpoint that accepts external requests should have rate limiting applied. Equally important is logging and monitoring — you need visibility into who is calling your APIs, at what volume, and whether patterns suggest enumeration or automated abuse.
Test specifically for API vulnerabilities
General web application scanning is not sufficient. API security testing requires specific tooling, specific methodology, and — critically — manual testing of business logic. Automated tools will find misconfigurations and some injection flaws; they will not find BOLA, logic vulnerabilities, or chained attack paths that require understanding how the application is supposed to work.
The organisations that get API security right are not necessarily the ones with the biggest budgets. They are the ones that treat APIs as a first-class security concern rather than an afterthought.
Final Thought
API security is not a new problem — but it is a growing one, and the gap between the pace at which APIs are being deployed and the pace at which security is catching up continues to widen.
The good news is that most API vulnerabilities are not exotic or difficult to address once they have been identified. Broken authorisation, excessive data exposure, missing rate limits — these are solvable problems. What they require is visibility, deliberate testing, and a willingness to treat API security as a discipline in its own right rather than a subset of general application security.
If you are unsure where your API security posture stands, the honest first step is to find out. An assessment does not have to be exhaustive to be valuable — even a focused review of your highest-risk endpoints will almost always surface findings worth acting on.