Contact
Phone & 24/7 emergency hotline+49 2932 465265-0 Emailinfo@rootsektor.deMon–Fri 8:00 a.m.–5:00 p.m. CET/CEST · outside business hours: 24/7 emergency hotline
Request a pentest quote Report an emergencyPenetration Testing
REST · GraphQL · SOAP · gRPC
APIs connect your web and mobile apps with partners, payment service providers, and cloud services – and often give attackers a direct path to your data. With API penetration testing, we manually examine your interfaces for broken authorization, weak authentication, and abusable business logic, guided by the OWASP API Security Top 10.
Definition
In API penetration testing, we examine your application programming interfaces specifically for exploitable vulnerabilities. We attack the endpoints directly – without going through a user interface – and investigate whether authentication, authorization, input handling, or business processes can be abused.
Hardly any modern application works without APIs. They feed data to single-page applications and mobile apps, connect partners and payment service providers, link microservices, and provide open banking interfaces under PSD2 (the EU’s revised Payment Services Directive). The user interface often shows only a fraction of what the API actually returns – such as complete customer records, internal fields, or functions that never appear in the front end.
Many of the most critical API vulnerabilities don’t stem from missing input filters but from missing authorization checks at the object, property, and function levels. A scanner can’t know that account A must not see account B’s invoices. That’s why we test multiple user accounts and roles against each other – exactly as an attacker would, using a legitimately registered account of their own.
If your APIs process personal data, payments, or health data, an API pentest also provides important evidence: for the effectiveness review under Art. 32 GDPR, for ISO/IEC 27001, PCI DSS 4.0.1, or DORA – and for customers and partners who rely on the security of your platform.
Our approach
Our starting point is your API documentation – for example, an OpenAPI or Swagger specification, a GraphQL schema, a WSDL file, Protobuf definitions, or a Postman collection. If there is none, we reconstruct the endpoints from the traffic of your web or mobile app and from the JavaScript code it delivers.
We test with at least two accounts per role so we can systematically check access across user and tenant boundaries. We examine the in-scope endpoints across their methods, parameters, and object IDs, and we analyze tokens such as JWTs or OAuth access tokens for signature, validity, and scope of permissions.
In addition to the OWASP API Security Top 10 (2023 edition), we develop custom test cases for your business processes. After all, the most dangerous flaws often hide in workflows that only your API implements in this particular way.
Common vulnerabilities
The API doesn’t check whether the requesting account is allowed to access a specific object. Replace order number 1042 with 1043 in a request, and you’re suddenly reading someone else’s data – number one in the OWASP API Security Top 10.
Missing protection against credential stuffing, accepted unsigned JWTs (“alg: none”), tokens that never expire, or API keys in the code of publicly distributed apps.
The API returns more fields than necessary or accepts additional fields from the request without validation – such as a role of “admin” (mass assignment).
Without rate limits and size and pagination limits, you risk brute-force attacks, mass data extraction, overload, or high costs for paid SMS, email, or AI services.
Administrative or internal functions are reachable from regular accounts – often, switching the HTTP method or guessing an admin path is all it takes.
Processes such as registration, ticket purchases, voucher distribution, or reviews can be abused through automation on a scale that harms your business.
The API fetches URLs it is given, for example for webhooks or file imports. Attackers can use this to reach internal services or cloud metadata containing stored credentials.
Forgotten legacy versions, test endpoints, and undocumented “shadow APIs” remain reachable – often without the safeguards of the current version.
API technologies
Every API technology comes with its own attack surface. Our test cases are tailored accordingly.
Resource-oriented
The most widespread API style – many endpoints, many object IDs, and therefore many places where authorization checks can be missing.
Query language
A single endpoint, but virtually unlimited query options – authorization has to be enforced on every field and in every resolver.
Enterprise & microservices
XML-based web services in ERP, banking, and public administration environments, plus gRPC for communication between microservices.
Process
Structured, closely coordinated, and with traceable results – following the same proven approach as all our penetration testing engagements.
We clarify which APIs, versions, and environments will be tested, which roles exist, and what documentation is available. Within 24 hours (on business days), you receive a fixed-price quote.
You provide the specification and at least two test accounts per role. For machine-to-machine interfaces, we need API keys or client credentials.
We catalog all endpoints, objects, and roles and derive concrete abuse scenarios from your business processes.
We test the in-scope endpoints against the OWASP API Security Top 10 and your specific scenarios, verify findings manually, and document them with request and response.
You receive an executive summary, technical findings with CVSS ratings, and concrete remediation recommendations – explained in a debrief on request.
We retest fixed vulnerabilities free of charge. With the test certificate, you can prove to customers, partners, and auditors that the test was carried out.
Reporting
For each vulnerability, we document the affected endpoint, the request used, and the API’s response – so your development team can reproduce every finding directly. The executive summary puts the results into context for senior management and shows where the greatest risk lies.
Find out whether it’s really locked. After scoping, you’ll receive a fixed-price quote within 24 hours.
FAQ
Didn’t find your question? Call us at +49 2932 465265-0 or email info@rootsektor.de.
A web pentest examines the application through the browser – including client-side risks such as cross-site scripting or clickjacking. An API pentest goes straight to the endpoints and focuses on authorization, tokens, data fields, and workflows, including interfaces without a user interface of their own, such as partner or machine-to-machine APIs. If your application has its own front end, the API test combines well with a web application penetration test.
Ideally, an up-to-date specification – such as OpenAPI, a GraphQL schema, WSDL, or Protobuf files – or a Postman collection, plus at least two test accounts per role and, where applicable, API keys. On request, we sign a non-disclosure agreement before any sensitive documents are exchanged.
Yes. In a black-box test, we reconstruct the endpoints from the traffic of your web or mobile app, from the JavaScript code it delivers, and from publicly available sources. That’s realistic, but it uses up testing time that a gray-box test with documentation and test accounts can invest in depth instead. For most APIs, we therefore recommend the gray-box approach.
The effort depends on the number of endpoints or operations, the roles and authentication methods, the complexity of the business logic, and the API technology. After scoping, you receive a fixed-price quote within 24 hours (on business days) – with no additional charges for the agreed scope and including a free retest.
Yes. We test internal interfaces either on site or remotely – via VPN or a provided test system in your network. We also examine communication between services, such as service-to-service authentication, mTLS, and trust in internal networks. If your services run in the cloud, the test combines well with a cloud penetration test.
An API gateway handles important tasks such as authentication, rate limiting, and logging. But whether account A may access account B’s object is decided by the business logic behind the gateway – and that’s exactly where BOLA, BOPLA, and BFLA arise. That’s why we test both: the gateway configuration and the authorization logic of the services behind it.
At least once a year and after significant changes – such as new endpoints, a new API version, changed authentication methods, or new integrations. With frequent releases, it pays to build targeted testing of changes into your development process.
Tell us about your interfaces, the technology you use, and your preferred dates. We’ll agree on the scope with you and send you a fixed-price quote within 24 hours of scoping – for companies in Germany and internationally.
Diese Seite gibt es auch auf Deutsch.