APIs are essential for communication between applications. An API pentest helps you to find security gaps and protect your customers' data.

API penetration tests are a specialized form of web pentests. APIs are often well documented, specifications are available (OpenApi, Swagger, WSDL, etc.), the attack surface is thus precisely defined and certain process steps of a penetration test can be skipped.

API Penetration testing

Pentest against application programming interfaces

The world is becoming more digital and software is increasingly communicating with each other - this happens with the help of so-called application programming interfaces (or APIs for short). APIs and interfaces are also increasingly found in modern websites and web apps as well as SPAs (Single Page Applications) - where you often find that the frontend and backend are strictly separated. The front end is some popular JS framework (AngularJS, ReactJS or VueJS) and the back end is accessible via an API. The developers must ensure that the API can only be accessed by authorized users.

Isn't an API pentest actually a web pentest?

This is basically the case. An API is an interface that is usually provided by some kind of application - often web applications. Logically, both the API pentest and the web pentest have similar vulnerabilities or security gaps with identical consequences for IT security. With API pentesting, the penetration test provider does not focus on the front end or web server, but only on the interface or even just parts of it.

Starting point of an API pentest

In an API pentest, we are actually always provided with the API documentation as a starting point. In 70% of cases, we are dealing with SwaggerUI or OpenApi. With the help of this specification, developers describe their API or each individual route including necessary and optional parameters, how these must be transferred and which HTTP response is expected. GraphQL (with activated introspection) is also a classic and very interesting special case of API. Rarer but no less interesting are APIs in which communication takes place using XML format - WSDL files as a starting point or the SOAP protocol are worth mentioning here. In general - the majority of our API pentest assignments are related to RESTful APIs. Topics in this area we covered in the past are penetration tests against systems with websocket APIs, JSON RPC and also gRPC.

Damian Strobel

The past has shown that APIs are an attractive target for attackers. Time and again, we read about APIs that can be found completely unprotected on the internet and spit out masses of personal user data.

Damian Strobel - Founder of DSecured

Let us test your API for security vulnerabilities and improve your cyber security.

Pentest Costs: Duration of the penetration test

Savings potential with API penetration tests

Similar to web penetration tests, we are flexible in the design of an API penetration test so that it fits into the budget. We often have to deal with huge APIs that are too expensive for the client to test in depth manually. A healthy mix of automated and manual tests is promising here. Everything is tested automatically, while the focus for the manual tests is placed on routes that interact with other services, execute processes, output/change user data or enable file uploads/downloads, for example. We are happy to take a look at the API in advance and give our recommendation. Details can be found in the article "How much does a penetration test cost?".

Methodology for API pentests

Hacking is a creative process. We don't just bluntly work through the OWASP API Top 10 - we see this as an absolute priority, but not the only one. We look at the API documentation, think about how data could be exfiltrated - what steps would have to be taken to do this and check whether this is actually feasible. Otherwise, the pentest methodology is not really any different from a regular penetration test against an IT system. We discuss the scope, define go/no-go criteria, then start the test and finally create a report.

Typical API security vulnerabilities

There are various types of vulnerabilities that can be found in APIs. The examples here are real examples from past penetration tests. Here you can find the most common ones:

Insufficient access rights

Time and again, an endpoint is found in such tests where the access authorization check has been completely forgotten. Such errors can be easily found automatically and analyzed manually later.


A simple change of a user ID in the HTTP request is often enough to access external data. This is an IDOR vulnerability (Insecure Direct Object Reference).

Cross Site Scripting (XSS)

XSS can also be found in API pentests. The special feature here is often that these are output in the context of a JS framework and identification is sometimes somewhat more complex.

Server side request forgery

The attacker can make the server send requests to other servers. This can lead to the server disclosing internal information or even sending requests to internal services. Such functions should be strictly isolated if they are required.

SQL Injections

The classic case - some parameter is not fully validated by the ORM and an attacker can access the database. Depending on the database system, this can quickly lead to a complete takeover of the web server. Particular caution is required here.

Undocumented routes

This is also something we often find. Developers have created a route but have not listed it in the documentation. That's a real treat for attackers, who may be able to access functions that are not actually intended for them.

Outdated components

Here, too, there are parallels to the web pentest. Outdated components are a gateway for attackers. The classic example here is old software that exports data internally to PDF or crawls URLs internally.

Unexpected behavior leads to XXE

The majority of APIs use JSON for communication. This can lead to unexpected behavior if, for example, the application is forced to accept an XML.

File processing without checking

Upload/download/processing of files is almost always seen in web applications. The data is sent to the API and not checked correctly there. The result can be manifold - in a negative sense.

Every API is different. Let us test your API for security vulnerabilities and improve it!

Some companies we have been able to help

Goldman Sachs
Contact DSecured

Request API Pentest