API Security Testing and Protection Service

Users see your mobile app, Google sees your website, but an attacker sees the API behind both. The screen is just a shell; the place where data actually flows is in those JSON endpoints where the app talks to the server. The pattern the DSET pentest team encounters most often in the field is this: a company has had its website tested, filed the penetration test report, declared "we are secure", while the thirty or forty API endpoints feeding that website sit untouched, undocumented, and often unknown to anyone. The real open door is right there.

There is a reason for this. A classic web application returns an HTML page, embeds data inside it, and wraps it in layers of presentation. An API offers no such courtesy. You ask for the object you want and it hands it back to you directly as JSON. For an attacker this is a gift: easy to parse, easy to automate, easy to scrape millions of records from in seconds. That is exactly why APIs leak far more data than classic web applications. A single flawed endpoint can carry your entire customer table out, row by row.

BOLA: number one on the OWASP API Top 10 and why it is so devastating

In the 2023 edition of the OWASP API Security Top 10, the list is headed by BOLA (Broken Object Level Authorization). The logic is embarrassingly simple, the impact catastrophic. Picture an endpoint: GET /api/v1/invoices/1043. That is your invoice. But what if you type 1044? In a sound system the server should say "this record is not yours" and shut the door. In weak systems it asks nothing and hands you someone else's invoice. By incrementing one id at a time you can walk an entire database.

Why is it so common? Because developers confuse authentication ("who are you") with authorization ("do you have the right to access this record"). The token is valid, the user is logged in, the system is satisfied. But which exact record that token's owner is entitled to see must be checked on every request, for every object, separately. Automated scanners almost never catch this, because they do not understand the business logic between two valid accounts. Only a tester who deliberately attempts cross access with two separate user accounts, by hand, finds it. Nearly all of DSET's BOLA findings come out of exactly this dual-account cross check.

BOLA's close relative is BFLA (Broken Function Level Authorization). Here the attacker reaches not for someone else's data but for a function above their own privilege. An ordinary user directly calls DELETE /api/v1/users/55 or POST /api/v1/admin/roles, an endpoint they would never see in the panel. There is no such button in the interface, but the endpoint is live and nobody asks "are you an admin".

Shadow API and zombie API: doors nobody knows about

The most insidious source of leakage we find in the field is endpoints that never appear in any documentation. We split them in two.

A shadow API is an endpoint absent from the official inventory, added quickly by a developer one evening, invisible to the API gateway, its existence unknown to the security team. A zombie API is an old version once documented but now abandoned: /api/v1 has moved to /api/v3 with a new release, everyone protects v3, but v1 is still up, still answering, and usually old, unpatched, vulnerable code. Nobody shut it down because nobody remembers it.

The danger is this: you cannot protect what you cannot see. Your WAF rule, your rate limit policy, your monitoring dashboard all look at endpoints you know about. Shadow and zombie endpoints fall outside exactly that oversight, which is why they are the first place an attacker visits. That is why at DSET every API test begins with an inventory and discovery phase; we derive endpoints not only from the documentation you provide, but also from traffic, the mobile app binary, JavaScript bundles, and traces of past versions. The real world, not you, defines the surface to be tested.

Why a WAF cannot see most API attacks

Many companies say "we have a WAF, we are protected". A WAF is good at catching known signatures, SQL injection patterns, script injection. But in BOLA the payload looks entirely legitimate: a valid token, a valid request, just the wrong id. To the WAF this is normal traffic. In excessive data exposure the server puts far more fields into the JSON than the client needs; password hashes, internal notes, other users' fields quietly come back, and even if the client never shows them, the data has already gone over the wire. The WAF cannot see this either, because there is no attack signature at all, only an overly generous response.

Add to that a lack of rate limiting. An authentication endpoint that accepts unlimited requests is an open invitation to brute force and user enumeration. Combined with BOLA the picture becomes clear: the attacker tries ids one by one, scrapes a record each time, and no frequency limit stops them.

OWASP API Security Top 10 (2023): a short map

Rank	Risk	What it looks like in the field
API1	BOLA, broken object level authorization	Accessing another user's record by changing an id
API2	Broken authentication	Weak JWT, non-expiring tokens, guessable sessions
API3	Broken object property level (excessive exposure + mass assignment)	Responses returning extra fields, writing role/privilege from the client
API4	Unrestricted resource consumption	No rate limit, no pagination, denial of service risk
API5	BFLA, broken function level authorization	An ordinary user calling an admin endpoint
API6	Unrestricted access to sensitive business flows	Critical operations abusable via automation
API7	Server side request forgery (SSRF)	The API making internal requests on the attacker's behalf
API8	Security misconfiguration	Open CORS, leaked stack traces, default settings
API9	Improper inventory management	Shadow and zombie APIs, undocumented endpoints
API10	Unsafe consumption of APIs	Blind trust in third-party APIs

This table sums up why a single scanner output is not enough. API1, API3, API5 and API6 are pure business logic; they can only be found by a human who understands what your application does, testing with two different accounts and deliberate abuse scenarios.

JWT, mass assignment and GraphQL: three frequently overlooked fronts

JWT vulnerabilities are the favorite nest of broken authentication. What we see often in the field: the signature algorithm being accepted as "none", the server never verifying the token signature at all, weak or leaked symmetric keys, a token expiry (exp) that never elapses, and tokens not being revoked on logout. Any one of these alone is enough to impersonate someone else.

Mass assignment is the server blindly writing every field from the client's JSON onto the object. You quietly add "role": "admin" to your profile update request; because the server does not filter it, it accepts it and you escalate your own privilege. Rare in classic web forms, this flaw is rampant in JSON-based APIs.

GraphQL is a front of its own. When introspection is left open, an attacker learns your entire schema, all types and all fields in a single query; they hold your map. With deeply nested queries they can exhaust the service with expensive requests, and if field-level authorization is missing they reproduce the very same BOLA from REST inside GraphQL.

How the DSET API security service proceeds

Our approach deliberately diverges from classic web penetration testing, because the API's threat surface is also different.

1. Inventory and discovery

We map the entire API surface, including shadow and zombie endpoints. We do not trust only the supplied documentation; we expose the real attack surface by examining traffic, the mobile app binary, front-end JavaScript and traces of old versions.

2. OWASP API Top 10 based penetration testing

We test the whole list, especially the business-logic items BOLA, BFLA, mass assignment and excessive data exposure, using accounts at at least two different privilege levels, by hand and with deliberate abuse scenarios.

3. Authentication and authorization auditing

We verify JWT configuration, token lifecycle, session revocation, and authorization checks for every object and every function separately. We examine "who are you" and "do you have the right" as two distinct questions.

4. Remediation and verification

For every finding we provide a concrete fix step the developer can apply directly; after the fix we retest to prove the gap is truly closed.

5. Continuous monitoring

A one-off test is a snapshot. New endpoints are born with every deployment; with continuous monitoring we keep the inventory live and catch new shadow APIs and privilege drift as they emerge.

Web application security still matters and we do it too; for details see our website security and penetration testing service. If you are curious about the general penetration testing process, when it is needed and how it is priced, our penetration test process article is a good start. For ongoing tracking of discovered flaws, review our vulnerability management service.

Frequently Asked Questions (FAQ)

How is API security testing different from a normal web penetration test? Web testing focuses on the pages visible in a browser. API testing focuses on the JSON endpoints behind them, the business logic and the authorization. Flaws like BOLA, BFLA and mass assignment are only found at the API layer, often tested by hand with more than one account. Neither replaces the other.

We already use a WAF, do we still need API testing? Yes. A WAF catches known attack signatures, but in flaws like BOLA and excessive data exposure the payload looks entirely legitimate. A valid token, a valid request, the wrong id; the WAF mistakes it for normal traffic. A WAF is complementary, it does not replace fixing the authorization flaw.

What are shadow API and zombie API, and why are they dangerous? A shadow API is an endpoint not in the inventory, added without the security team's knowledge. A zombie API is an abandoned old version. Both fall outside monitoring and protection coverage, which makes them the first place an attacker visits and the easiest to leak data.

We use GraphQL, is it safer than REST? No, just different. Open introspection exposes your whole schema, missing field-level authorization reproduces REST's BOLA, and nested queries create service load. GraphQL has a testing discipline of its own.

Is testing once enough? A one-off test is only that day's photograph. Every new deployment can spawn new endpoints and new shadow APIs. That is why we recommend continuous monitoring that keeps the inventory live; risk is not ended in one shot, it is managed.

Sources

DSET - cyber security and penetration testing since 2003. Address: Hacettepe Teknokent, Beytepe, Ankara, Turkey. Phone: +90 536 662 38 09. The initial assessment and scoping call is free.