Web application and API penetration testing

The framework is OWASP ASVS (Application Security Verification Standard) version 5.0 from May 2025, a catalog of application security requirements, and the OWASP Web Security Testing Guide, stable version 4.2, which describes how each requirement is verified. That makes the test repeatable, and you know what was done. For APIs we add the OWASP API Security Top 10, 2023 edition, because an API fails differently from a web interface: it has no screen to constrain the user.

In practice that means seven groups, named by what breaks in them rather than by the ten categories of the OWASP Top 10: authentication and session management, authorization between roles, input handling (injection, XSS, file uploads), business logic, server and header configuration, handling of sensitive data, and third-party interfaces. We test each group by hand and verify a finding before it goes into the report.

We never test an application only as an anonymous visitor. For every role the application has, we need a dedicated account, because the biggest findings show up between roles, not in front of the login screen.

This page covers a web application and its API as used from a browser. We test a mobile application and its backend separately, because a mobile client is tested with different techniques than a web interface.

A scanner finds a missing header and an old library version. It won’t find that someone else’s order gets approved by swapping one identifier in the request, or that a password reset issues a valid token without checking who owns the mailbox. The first is called an insecure direct object reference, IDOR for short, and OWASP lists the same flaw for APIs under the name Broken Object Level Authorization as item API1:2023. A scanner has no way to get there: it doesn’t understand what each role in your application is allowed to do.

This is what an object-level authorization flaw looks like. A user with the accountant role opens an invoice detail, the document number is in the URL, and after changing it the invoice of another branch office appears. The application checks that the user is logged in, but not that the document belongs to them. Into the report go the request, the response, a screenshot, and the four steps a developer follows to reproduce it.

The second group is business logic, where every flaw is different. A discount can be applied twice, an order can be confirmed without payment, a transfer limit is bypassed with a negative number. This can’t be automated, because only someone who understands the application knows what correct behavior is.

We recommend gray box as the default. We get accounts for every role and a basic description of the application, but not the source code. In the same number of days we cover considerably more functionality than in a black-box test, where the first two days go to finding out what the application can even do.

Black box makes sense when you want to see how far an attacker gets without a single account, typically with a public portal or an online store. Source code is worth adding for an application with a lot of custom cryptography or complex authorization logic: it doesn’t replace the test, but it speeds up the search and raises coverage. What the three variants mean in general, and why they mean something different for a network than for an application, is covered by the glossary entry on the three levels of knowledge and what each one reveals.

Five things, and it helps to have them ready before the scope is signed. First, the list of roles the application has, with two accounts per role, so we can test access to other people’s data within the same role. Second, the environment we test on, and whether it holds a copy of production data. Third, a contact for the developer or the vendor in case something stops working.

Fourth, a decision on the web application firewall (WAF). If you leave it on, we test through it and some findings hide behind blocked rules. We recommend two phases: first a test with our IP address allowlisted, to show the real state of the application, then a short check of what the WAF catches in live operation. Without the exception you’re measuring the quality of the filter, not the quality of the application.

Fifth, the dates. The test runs on business days, and if the application sends customers emails or text messages, turn off outbound sending for the duration of the test or tell us. The test process, the classification of findings, and the report format are the same for all our tests and described in one place: how our test runs from scoping to retest.

The best option is a test environment that is a faithful copy of production. We test at full strength, writes included, and nobody minds that two hundred test records showed up in the orders. There is one condition: it must run the same code version and the same configuration; otherwise you’re testing something your customers don’t use.

We test in production too, with limits. Operations that would damage or delete data we verify by reading only, and we try writes on our own test accounts. We tag everything we create and send you a list at the end so you can clean up. We call before risky steps.

We calculate effort from three variables: the number of user roles, the number of screens or endpoints, and whether an API and an administration interface are included. A small customer portal with two roles takes roughly two weeks; a large online store with administration, a loyalty program, and a partner API takes three.

What drives the effort up most isn’t the number of pages but the number of combinations of roles and states. An application with four roles and a three-step approval process has more transitions to test than an application with twenty static screens. That is exactly what drives the effort of an application test, and with it the duration you’ll see in the proposal.

For an online store the core of the test is the cart and the payment: applying a discount, changing the price on the client side, completing an order without paying, and reaching someone else’s order through the document number. Then the integrations with the payment gateway and the carriers. Those run server to server and authorize with a key or a token, so the user’s login doesn’t cover them and the application has to handle their permission checks separately.

A customer portal stands or falls on account separation. We test if a customer can reach another customer’s documents, if registration can claim someone else’s email address, and what the error messages give away. With internal applications it’s the reverse and comes down to roles: an accountant gets into HR records, a temp sees supplier price lists.

Internal applications also tend to have weaker authentication, because the assumption is that nobody outside will ever see them. That holds until someone gets into the network. An application test doesn’t check that assumption; that is what a test of the infrastructure the application runs on is for.