Web Application Penetration Testing: A Buyer's Guide for 2026
Most of the penetration test reports we are asked to review are not penetration tests. They are vulnerability scans wearing a suit. Someone pointed an automated tool at a URL, exported a PDF with a CVSS colour chart, slapped a logo on the cover, and invoiced you for it. The tool found an outdated jQuery version and a missing security header. It did not find the broken access control that lets one customer read another customer's invoices, because no scanner on earth understands that your invoices belong to a tenant.
That gap is the whole reason you buy a web application penetration test. So before you shortlist a vendor or sign a scope document, it helps to know what a real one actually involves, what a good report looks like, and how to write a scope that gets you the depth you are paying for. This is the buyer's guide we wish more of our clients had read before their first engagement.
Scan, assessment, penetration test: they are not the same thing
The words get used interchangeably in sales calls, and that ambiguity is where you overpay for less. A vulnerability scan is automated and mostly signature-based. A vulnerability assessment adds some human triage on top. A penetration test is a human trying to break in, chaining weaknesses the way a real attacker would, to prove exploitability and business impact. The price and the value scale accordingly.
| Activity | Who runs it | Finds | Typical cost (INR) |
|---|---|---|---|
| Vulnerability scan | A tool (Nessus, Acunetix, Burp scanner) | Known CVEs, missing headers, outdated components | 20,000 - 60,000 |
| Vulnerability assessment | Tool plus analyst triage | Above, minus false positives, with severity context | 60,000 - 1,50,000 |
| Web app penetration test | A tester manually, tools as assist | Logic flaws, broken access control, chained exploits, real impact | 1,50,000 - 6,00,000+ |
If a proposal quotes you sixty thousand rupees for a penetration test of a customer-facing application with authentication and payments, you are buying a scan. That is fine if a scan is what you need. It is not fine if your CERT-In empanelled auditor letter, your PCI DSS assessment, or your enterprise customer's security questionnaire is expecting a real test behind it.
What actually happens in the room
A competent test follows a methodology rather than the tester's mood on the day. The reference frameworks are the OWASP Web Security Testing Guide, which is the closest thing the industry has to a checklist of what to test, and the OWASP Top 10, which is the widely quoted list of the most common and dangerous web application risk categories. A good tester uses the WSTG as a coverage map and the Top 10 as a way to explain findings to your board. Here is roughly how a two-week engagement unfolds.
Week one: understand the application, then attack it
- Reconnaissance and mapping: enumerate every page, endpoint, parameter, API route and hidden function. You cannot test what you have not found. Half the value of grey-box testing is that we find endpoints a black-box tester never would.
- Authentication and session testing: password policy, brute-force resistance, session fixation, token entropy, logout behaviour, multi-factor bypasses, and whether a session survives a password change.
- Authorisation testing: this is where the money is. Can a normal user reach an admin function by guessing the URL? Can user A read user B's records by changing an ID in the request? This is broken access control, the number one risk in the current OWASP Top 10, and it is invisible to scanners.
- Input handling: injection (SQL, NoSQL, command, LDAP), cross-site scripting, server-side request forgery, insecure deserialisation, file upload abuse, and template injection.
Week two: business logic, chaining, and proving impact
- Business logic testing: can you apply a coupon twice? Set a negative quantity to get a refund? Skip the payment step and still receive the goods? Reset another user's password by racing two requests? No tool tests these. A human who understands your workflow does.
- Chaining: a low-severity information disclosure plus a weak password reset plus a predictable token becomes full account takeover. The report should show the chain, not three unrelated tickets.
- Impact demonstration: a real test proves what an attacker gets. Not this parameter is vulnerable to SQL injection but here is the extracted user table with 40,000 email addresses and hashed passwords, which is what your DPDP Act breach-notification obligation now attaches to.
A scene from an actual test
A fintech client gave us grey-box access to their lending portal. The automated scan they had run the previous quarter was clean. Green across the board. Within the first day, we noticed the loan application reference in the URL was a simple sequential integer. We incremented it. The application loaded another borrower's full application: PAN, Aadhaar last four digits, bank statements, salary slips, sanction amount. No error. No access check. Just their data on our screen.
Then it got worse. The document download endpoint used the same pattern, so every uploaded KYC document for every borrower was retrievable by anyone with a valid login and a for-loop. That is an insecure direct object reference, a classic broken access control flaw. For a lender, it is also a reportable personal data breach under the DPDP Act, a likely RBI supervisory conversation, and the kind of thing that ends up on the front page. Their scanner never had a chance of finding it, because to the tool one integer looks exactly like another. To a human who understood these were two different people's financial lives, it was obvious in seconds.
Black-box, grey-box, white-box: choose deliberately
The access you grant the tester is the single biggest lever on how much you learn. People default to black-box because it feels like the most realistic simulation of an outside attacker. In practice it is usually the worst value, because your tester burns half the budget on reconnaissance that a five-minute credentials handover would have solved.
| Approach | What the tester gets | Best for | Trade-off |
|---|---|---|---|
| Black-box | A URL and nothing else | Simulating an anonymous internet attacker | Time wasted on discovery; deep flaws often missed within budget |
| Grey-box | Test credentials for each user role, some architecture context | Almost all commercial web apps | The pragmatic sweet spot; best coverage per rupee |
| White-box | Credentials plus source code and design docs | High-assurance apps, payment systems, first test of a critical app | Costs more; requires the tester to actually read code |
Our standing advice: for any authenticated application, do grey-box at minimum, and provide at least two accounts per privilege level. You cannot test whether user A can reach user B's data if you only have one user. That single decision is the difference between a test that finds broken access control and one that certifies you as safe while you are not.
What a real report contains
You are not buying the test. You are buying the report, and the retest that proves you fixed things. A report that lists findings without proof, business context, or clear remediation is a liability, not an asset. When you read a sample report during vendor selection, look for these.
- An executive summary a non-technical director can act on: what is the worst thing an attacker can do today, and how exposed are you.
- Each finding with a severity, an affected endpoint, a reproducible proof of concept (the exact request), the business impact in your terms, and a specific fix, not fix input validation but parameterise this query.
- A clear scope and methodology statement naming the OWASP WSTG coverage, so an assessor or customer can see what was and was not tested.
- An attestation letter or certificate you can hand to auditors and enterprise procurement, signed by the empanelled entity.
- A free retest clause, so once you remediate, the tester verifies and reissues a clean letter. A finding is not closed until someone has tried to exploit it again and failed.
Beware the auto-generated report. If every finding reads like tool boilerplate, uses generic CVSS text, and never mentions your application's actual function, a machine wrote it. You paid for a human and got a printout.
How to scope a test that is worth the money
Bad scoping is the most common way buyers waste this budget. Either they scope so vaguely that the vendor sandbags, or so narrowly that the important thing is out of scope. Get these decisions right before the kick-off call.
Decisions to make before you sign
- Define the target precisely: which application, which domains and subdomains, which APIs. An app plus its mobile backend API is two attack surfaces, not one.
- Count the roles: how many distinct privilege levels exist (anonymous, customer, staff, admin, super-admin), and provide two accounts for each. Pricing scales with roles because authorisation testing scales with roles.
- Environment: test against a staging environment that mirrors production, or accept that production testing needs a change window and destructive tests are off the table.
- Set the rules of engagement in writing: test window, source IPs to whitelist, out-of-scope actions (no denial-of-service, no data deletion), and an emergency contact for both sides.
- Decide on effort in person-days, not a flat fee. A meaningful test of a mid-sized application is 8 to 15 tester-days. If a quote implies two days, ask what they are skipping.
Where the Indian regulatory context bites
Depending on who you are, this test is not optional and the standard is not yours to set. Match the engagement to the obligation so you are not testing the wrong thing to the wrong depth.
| If you are | The expectation | Practical implication |
|---|---|---|
| A regulated financial entity | RBI cyber-security framework and annual VAPT by a CERT-In empanelled auditor | Empanelment of the vendor is non-negotiable; keep the attestation letter for supervisory review |
| Handling cardholder data | PCI DSS requirement 6.4.11 and 11.4 (application and penetration testing) | Test must follow an industry methodology and cover the whole cardholder data environment |
| Processing personal data at scale | DPDP Act reasonable security safeguards and breach notification | Findings like the IDOR above are potential reportable breaches; document remediation |
| Selling to enterprises | A customer security questionnaire demanding a recent third-party pen test report | A scan will fail their review; they will ask for methodology and retest evidence |
The fix-it checklist before you request a test
You will get more from the engagement, and a cleaner report, if you tidy the obvious first. Walk this list a week before the tester starts.
- Provision and share two accounts per user role, plus any test payment cards or sandbox keys.
- Confirm the test environment has representative data, not an empty database that hides authorisation flaws.
- Whitelist the tester's source IPs and warn your SOC and WAF vendor so they do not block the test on day one.
- Freeze deployments during the test window; a moving target produces findings that no longer exist by report time.
- Nominate one technical point of contact who can answer questions and reproduce issues in real time.
- Agree the retest window up front, so remediation does not drift for three months and leave you exposed the whole while.
- Ask for the raw request evidence with every finding, so your developers can reproduce and verify each fix themselves.
The point of all this
A vulnerability scan tells you which known doors have known weak locks. A penetration test tells you whether a determined person can get into your house, what they can take, and how much it will cost you when they do. Those are different questions, and only one of them is the one that keeps your customers' data, your regulator, and your board off your back. Buy the one you actually need, scope it honestly, and read the report like your reputation depends on it, because it does.
If you want the test done by people who have sat in the audit room and pulled another borrower's KYC out of a lending portal by incrementing a number, our team at CyberSigma are senior CERT-In empanelled auditors and PCI QSAs who do this hands-on, not by tool. We are happy to review a scope with you before you commit to anyone.
FAQs
How long does a web application penetration test take?
For a typical mid-sized application, budget 8 to 15 tester-days of effort spread over two to three calendar weeks, plus about a week for reporting and a retest window after you remediate. Very large or complex applications with many roles and APIs take longer. Anything quoted at two or three days is almost certainly an automated scan rather than a real test.
What is the difference between VAPT and a penetration test?
VAPT stands for Vulnerability Assessment and Penetration Testing and is the umbrella term Indian regulators and RBI-regulated entities usually use. The vulnerability assessment part is broad and largely automated; the penetration testing part is the deep, manual, exploit-driven work. When RBI or a customer asks for VAPT they generally expect both, with a CERT-In empanelled auditor behind the penetration testing element.
Should I choose black-box or grey-box testing?
For almost every authenticated application, choose grey-box and provide at least two accounts per user role. Black-box wastes budget on reconnaissance and routinely misses broken access control because the tester never fully maps the app. Reserve pure black-box for when you specifically want to measure external attacker exposure with no inside knowledge.
Does a penetration test satisfy PCI DSS and RBI requirements?
It can, if it is scoped and executed to their standard. PCI DSS requirements 6.4.11 and 11.4 expect application and penetration testing to a recognised methodology across the cardholder data environment. RBI-regulated entities need annual VAPT by a CERT-In empanelled auditor with a signed attestation. Keep the report, the methodology statement and the retest letter as evidence for assessors and supervisors.
Why did our automated scanner report the application as clean when it was not?
Scanners find known patterns: outdated components, missing headers, some injection. They cannot understand your business logic or your data ownership model, so they never notice that one user can read another user's records by changing an ID. Those broken access control and business logic flaws are exactly the findings that cause real breaches, and only a human tester who understands your application finds them.
What should I look for when reviewing a sample penetration test report?
Look for an actionable executive summary, findings with reproducible proof-of-concept requests, business impact written in your terms, specific remediation rather than generic advice, a clear OWASP-based methodology and scope statement, a signed attestation, and a free retest clause. If every finding reads like tool boilerplate and never references your application's actual function, a machine wrote it and you overpaid.
Liked the post? Share on:
Leave A Comment