Web Application Penetration Testing for Enterprises: Test the Journeys, Not Just the Pages
A web application is really a collection of jobs. A buyer places an order, a seller changes a price, a support agent looks up an account, an admin issues a refund. The pages are rarely the problem. The trouble starts where one person’s job brushes against another’s, and a scanner reading page after page never sees it. So we test your application the way each of those people uses it, logged in as each of them, and we try the things each of them shouldn’t be able to do. This page is for security and product leads at companies that earn money or hold customer data through a web application.
Five weeks before its biggest sale
A large e-commerce platform came to us with its biggest sale five weeks away. It had been hit by voucher abuse before, and it knew carts, vouchers and payment confirmations run on business rules that an automated scanner doesn’t understand. It wanted to know what a customer could do with them before the sale did.
We mapped the journeys of a buyer, a seller and an admin, from browsing the catalog through to refunds, and tested as each one. The testing ran in a staging environment with realistic data. Automated test packs went through the usual ground, and a tester then checked every high and critical result by hand. We found 34 issues: 2 critical, 5 high, 12 medium and 15 low. Three of them are worth telling.
A discount code that was never meant to be public could be combined with free shipping and cashback until the order total hit zero. We reproduced it three times. A script left in the product Q&A section could take over a seller’s admin session. And the system accepted payment confirmations marked “paid” without checking their digital signature, so an order could be marked paid when no money had moved.
For the high and critical findings, the developers got the requests, the responses, a video and the steps to reproduce them, so nobody had to take our word for it. The logic fixes went in before the sale. Payment confirmations are now signed, checked and processed only once, and a retest confirmed that the critical and high findings were closed. The platform now runs the same tests before every promotional release. The published case study has the rest.
Start with the roles
Look at the second of those three findings. The script sat in a part of the product page where users post questions, and the person it put at risk was a seller, through the seller’s admin session. Nothing on either page was broken in the usual sense. The risk was in what content one person posted could do to another person’s session.
That is why we test logged in: you provide one test account for each role in scope, so we can see what a customer, a seller or an admin sees, and then try to reach across. Can a customer open another customer’s order by changing a number in the address bar? Can a support agent do an admin’s job? Can a role you retired last year still sign in? An outsider’s view of your login page finds some of this. It won’t find the rest.
Where the business rules live
These two findings aren’t a broken library or a missed patch. They’re rules: nothing in the system said a discount may not stack, or that a payment message must be signed. A scanner can’t know your rules.
So we read your journeys for the places where a rule decides who gets money, goods, data or access. Carts and vouchers are the obvious ones. Refunds, approvals and transfers come next, and then anything else that moves a record from one state to another.
Then we try them out of order, twice in a row, and with a colleague’s ID in place of our own. In the case above, that is where the order hit zero.
The ground every web test covers is covered as well: login and session handling, access control, input handling such as injection and cross-site scripting, and file upload and download. We work from the OWASP Web Security Testing Guide and OWASP ASVS, alongside PTES and NIST SP 800-115, and we score severity with CVSS.
Staging, or the live service
The environment, staging as in the case above or the live service, is set in the written scope. Either way, the rules are agreed in writing before we start: what we test, when and how. Testing is paced so a live system keeps running, and senior testers control the pace.
What this page leaves out
Mobile apps, denial-of-service and load tests, and anything the written rules leave out stay out of this work. Mobile apps are covered under application security testing, and reading code line by line is a separate service, source code review. If your risk lives mostly in the requests beneath the screens, start with API penetration testing.
Questions that come up
We run a scanner in our pipeline. What’s left for a person to do? The scanner is good at known weaknesses in known places. A person decides whether a coupon, a shipping offer and a cashback can be combined, and then does it.
Do you need accounts for every role? For logged-in testing, you provide one test account for each role in scope. If a role is left out, we say clearly that it wasn’t tested.
Can we test just one journey, like the new checkout? Scope is agreed in writing, so a single journey can be the scope. We’ll tell you if a neighboring one is worth adding.
What the report is for
The report is written for three readers at once. The head of product wants to know whether the sale date is safe. Your developers want the request that breaks it. Your auditor wants to see it tied to a control. Anything we couldn’t show to be real stays out of it.
If the application sits inside your cardholder data environment, PCI DSS requirement 11.4 asks for penetration testing at least every 12 months and after significant changes. Our findings are also mapped to ISO/IEC 27001:2022, SOC 2 and OWASP ASVS, and what an auditor accepts is always the auditor’s call. Our guide to penetration testing for compliance explains what they tend to look for, and how an engagement runs is on the penetration testing page.
Bring the release date
Tell us which roles, which journeys and which date, and in the free 90-minute scoping session we’ll turn that into a scope you can sign off. If details are sensitive, we sign an NDA first. A scoped proposal follows within 24 hours, and the report comes within 10 business days of testing, with the retest included. We work with e-commerce and retail companies and with technology and SaaS providers, and the approach is the same.
Book a free 90-minute scoping session · Request a scoped proposal