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.
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.
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.
IDOR
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
Further questions and answers on the topic
"API penetration testing"
How long does API penetration testing typically take?
The duration of an API test depends on the number of endpoints, parameters and the general complexity of the API. Most tests can be completed within 1 week. However, 2-3 weeks would not be unusual.
What should I expect in the report from API penetration testing?
Expect a comprehensive report that includes not only technical details and vulnerabilities spotted but also actionable recommendations & a management summary that's straightforward yet detailed. Our reports ensure clarity & provide value-driven insights.
Who actually conducts the API penetration testing at DSecured?
Our API penetration tests are carried out by certified& highly skilled penetration testers who understand the intricacies of API security. Our team combines years of sharp experience & creative problem-solving capabilities to enhance your platform's security.
What kind of security flaws does an API security audit reveal?
API penetration tests focus on the classic web security vulnerabilities. We see SQL injections, IDOR and code injections time and again. But basically anything is possible - depending on the purpose of the API.
How frequently should we conduct an API security test?
Clear recommendation: As often as it makes sense - for example at launch, relaunch, significant changes to the code, server moves or changes to the API structure. Most customers test their API once a year. We recommend something like Pentest as a Service in order to be able to intervene selectively.
Can API security testing disrupt our day-to-day business?
Normally not, as we mostly work in an isolated test environment or at predetermined time slots with low utilization to avoid interruptions. We communicate closely with your IT team to prevent down times etc. However, preparation for such an API pentest is always advisable.
What post-test support do you offer post-API security analysis?
Post-testing, DSecured provides detailed follow-up support to help your team address the uncovered issues. Our support includes clarification sessions, rectification suggestions, and re-tests to ensure vulnerabilities are thoroughly resolved.
Request API Pentest