Web Application Penetration Testing · United Kingdom
Web application penetration testing. The logic flaws a scanner will never find.
Automated tools catch injection and missing headers. They do not catch the checkout that lets a user change the price, or the API that returns another customer’s record when you edit one digit. We test both, and hand you the exact request that worked.
CREST-certified operators · OWASP Top 10 and business logic · APIs included · every finding human-verified
What is web application penetration testing?
Web application penetration testing is an authorised attack on a web application, its API and the logic behind them. A tester works through the OWASP Top 10, then goes further into the behaviour that is specific to your application, and proves which weaknesses a real attacker could use.
The distinction that matters is between technical flaws and logic flaws. A scanner finds technical flaws well: injection, cross-site scripting, missing security headers. Logic flaws need a person, because they involve doing something the application allows but should not: skipping a payment step, approving your own request, reading a record that belongs to someone else by changing an identifier.
Broken access control has sat at the top of the OWASP Top 10 since 2021, and it is almost entirely a logic problem. That is the class we spend most of the engagement on.
What we attack
The OWASP Top 10, then the part that is yours
Every assessment starts where an attacker would: outside, watching, looking for the one door left ajar. We find it, then we show you the walk-through.
| Class | What we test |
|---|---|
| Broken access control | Whether one user can read, edit or delete another user’s data by changing an identifier, replaying a request, or calling an API endpoint the interface never shows them. |
| Authentication and sessions | Password policy, multi-factor bypass, session fixation, token handling, password reset flows and the account recovery path that lets an attacker in through the side. |
| Business logic | Price and quantity manipulation, skipped workflow steps, self-approval, race conditions at checkout, and any place your application trusts a value the browser sent. |
| Injection and output handling | SQL, command and template injection, cross-site scripting, and unsafe deserialisation, proven with the payload that worked. |
| APIs | The API behind the interface, tested directly. Undocumented endpoints, missing authorisation on individual methods, and mass assignment. |
| Configuration and components | Exposed configuration and debug interfaces, verbose errors, out-of-date components with known exploits, and file upload handling. |
What you get
The request that worked, with the fix beside it
Every assessment starts where an attacker would: outside, watching, looking for the one door left ajar. We find it, then we show you the walk-through.
- Every finding reproduced: the exact request, the response, and the steps to repeat it
- Findings ranked by business impact rather than a generic severity score
- The fix written for your developers, at the layer where it belongs
- Coverage against the OWASP Top 10, so your client questionnaires have an answer
- Verified by a CREST-certified operator before it reaches you
- A free retest of every fixed finding, so you can close the report properly
Before you ask
Web application penetration testing, answered
Every assessment starts where an attacker would: outside, watching, looking for the one door left ajar. We find it, then we show you the walk-through.
What is web application penetration testing?
Web application penetration testing is an authorised attack on a web application and its API, carried out by a tester rather than a tool. It covers the OWASP Top 10 classes, including broken access control, injection, authentication weaknesses and misconfiguration, and then goes into the business logic specific to your application. Every finding is proven with the request that worked and handed back with the fix at the layer where it belongs.
Do you test APIs as well as the web interface?
Yes, and we test the API directly rather than only through the interface. That distinction produces most of the authorisation findings in a typical engagement, because applications frequently hide a dangerous option in the front end while leaving the underlying endpoint open to anyone who calls it. We work from your documentation where it exists and map undocumented endpoints where it does not.
Can an automated scanner replace a web application penetration test?
For part of the job, yes. Scanners are good at injection, missing headers and out-of-date components, and running one continuously is sensible. They cannot find logic flaws, because a logic flaw is the application doing exactly what it was built to do in a situation nobody considered. No tool knows that your discount code should not stack with itself, or that a user in one branch should not approve their own expense claim. A person has to try it.
Do you need source code or a test environment?
Neither is required, and we run plenty of engagements as pure black box. Giving us credentials for each user role produces considerably more value, because most of the serious findings involve crossing a boundary between two roles, and we cannot cross a boundary we cannot see. We prefer a staging environment that mirrors production, but we can test production carefully under agreed rules if that is what exists.
Go deeper
Find the logic flaw before a customer does.
Get a free audit