Ask most people what a web application test looks for and they will say the OWASP Top 10. It is a reasonable answer and it is also where the conversation usually stops, which is a shame, because the Top 10 is a starting point rather than a syllabus. The findings that change a client’s risk position are rarely the ones with a neat category name.

Scanners find the easy half

Automated tooling is good at what it is good at. Missing headers, outdated components, obvious injection points, known CVEs in known software. Run the tools, absolutely. They clear the ground.

What they cannot do is understand your application. A scanner does not know that a user on the basic plan should not be able to reach the billing endpoint. It does not know that the discount code field should not accept a negative number. It does not know which of your two hundred parameters is the one that matters. It has no concept of what your application is for, so it cannot tell when something is being used in a way it was never meant to be.

That is where the interesting findings live.

Broken access control, over and over

If I had to name the single most common serious finding in web application testing, it would be access control. Not because it is exotic but because it is genuinely hard to get right and very easy to get subtly wrong.

The pattern is always some version of the same thing. An identifier in a request that the server trusts without checking it belongs to you. Change the order number, see someone else’s order. Change the user ID, read another account. An admin function that is hidden from the interface but still answers if you ask it directly.

These are unglamorous and they are frequently critical, because they usually mean any authenticated user can reach any other user’s data. That is a breach, and it is a breach that leaves no trace of an exploit because technically nothing was exploited. Someone just asked politely.

Business logic, which no tool can test

Every application encodes assumptions about how it will be used. Business logic testing is the practice of ignoring those assumptions.

What happens if you apply the discount twice. What happens if you go through the checkout steps in a different order. What happens if you cancel the payment but complete the confirmation. What happens if the quantity is negative, or enormous, or a decimal. What happens if two requests arrive at the same moment and both check the balance before either updates it.

None of this appears in a scanner report because none of it is a vulnerability in the traditional sense. Every individual request is valid. The application does exactly what it was told. The problem is what it was told to do.

Finding these requires understanding what the application is for, which is why the manual portion of a web test is the portion worth paying for.

Authentication and session handling

Login is the front door and it attracts a lot of attention, though usually not in the way people expect. The interesting problems are rarely in the password check itself.

They are in what happens around it. Whether the reset token is predictable or long lived. Whether the session actually terminates on logout or just disappears from the interface. Whether multi factor authentication can be skipped by going straight to the post authentication endpoint. Whether the login response tells an attacker that an account exists, which turns a password spray from guesswork into a targeted exercise.

The API behind the application

Modern applications are usually a thin front end talking to an API, and the API is frequently the weaker of the two.

The front end enforces rules. It hides the admin button, greys out the field, validates the input before sending it. None of that is security, because none of it exists on the server. If the API does not repeat every check the interface makes, then the interface is a suggestion rather than a control.

This is why testing an application through its interface alone misses things. The interface is the polite way in. Nobody attacking you will use it.

Injection is not finished

SQL injection has been well understood for over twenty years and it is still found, though less often in the obvious places. It has moved into the corners. Reporting features, search filters, export functions, anywhere a developer built a query by hand because the framework did not fit the job.

The same applies to the newer varieties. Server side template injection, deserialisation issues, injection into a NoSQL query that somebody assumed was immune because it is not SQL.

What a good test needs from you

Credentials at every permission level. This matters more than anything else. An unauthenticated test of an authenticated application tests the login page and very little else. If you have three user roles, I want an account for each, because most of the serious findings are about what one role can reach that it should not.

A staging environment if you have one, so the noisier testing does not land on production. And a heads up about anything fragile, so we can schedule around it rather than into it.

Give a tester those things and the time goes on finding real problems rather than knocking on the front door.