Web Application Penetration Testing: What Indian Companies Need to Know
Most of the web application "penetration tests" we are asked to review turn out to be automated scans with a logo on the cover. The report lists a few missing security headers, an outdated jQuery version, and a TLS warning — and says nothing about whether a logged-in user can read another customer's data by changing an ID in the URL. That gap, between what a scanner finds and what an attacker actually does, is the entire reason manual penetration testing exists.
For a business in India, the stakes are also regulatory. CERT-In expects empanelled testing and six-hour incident reporting; the RBI and SEBI tie security testing to supervisory obligations; and the DPDP Act, 2023 makes inadequate safeguards a liability, not just a risk. This guide is about what a web application penetration test should actually do, what separates a real one from a scan, and what to demand from whoever runs it.
What a web application penetration test actually is
A penetration test simulates how a real attacker would compromise your application — not just whether a known-vulnerable component is present, but whether your specific application logic, authentication, and access controls can be broken. A scanner checks a list. A tester asks a question the scanner cannot: given what this app lets a normal user do, what can I make it do that it shouldn't? The difference shows up most in business-logic and access-control flaws — the findings that actually cause breaches, and which automated tools almost never catch.
The useful distinction is depth of access, not the "black-box vs white-box" label vendors lead with. Black-box testing (no credentials) tells you what an anonymous attacker sees. Grey-box testing (with real user accounts across roles) is where almost all serious findings come from, because most damaging attacks start from an authenticated session — a legitimate user escalating privilege or reaching data they were never meant to see. For most web apps, grey-box with two or three role levels is the sweet spot; anything that skips authenticated testing is leaving the highest-impact surface untested.
What good testing finds that scanners miss
The OWASP Top 10 (2021) is a useful map of where real risk concentrates. The categories that matter most on a manual test — and that scanners handle worst — are:
- Broken access control (A01): IDOR, missing function-level checks, privilege escalation. The single most common serious finding, and almost entirely invisible to automated scans because it requires understanding who should be allowed to do what.
- Injection (A03): SQL, NoSQL, OS command and ORM injection — scanners find the obvious ones, testers find the parameterised and second-order cases.
- Insecure design (A04): logic flaws that are not bugs in code but flaws in the flow — coupon stacking, race conditions in payment or balance updates, workflow steps that can be skipped.
- Security misconfiguration (A05): default credentials, verbose errors leaking stack traces, over-permissive CORS, exposed admin interfaces.
- Identification and authentication failures (A07): weak session handling, flawed password reset, missing or bypassable MFA, JWT handling mistakes.
- Server-side request forgery (A10): increasingly critical for cloud-hosted apps, where an SSRF can reach the metadata endpoint and hand an attacker cloud credentials.
Notice how many of these depend on understanding the application rather than fingerprinting it. That is the line between a test and a scan.
How a real engagement runs
A credible test is structured, but the structure is in service of coverage, not a checklist for its own sake:
- Scoping and threat modelling: enumerate every role, endpoint, and sensitive workflow, and agree what "critical" means for this app. Scope defined badly is the most common reason tests miss the thing that later gets breached.
- Reconnaissance and mapping: map the real attack surface — APIs behind the UI, forgotten subdomains, staging that leaked to production.
- Manual testing per the OWASP WSTG: authenticated and unauthenticated, across roles, with automated tooling used to widen coverage, not to replace judgement.
- Exploitation and impact: prove the finding is real and show what it actually reaches — a theoretical XSS and an XSS that steals an admin session are not the same severity.
- Reporting: each finding with reproduction steps, evidence, business impact, a concrete fix, and a severity you can defend to an auditor.
- Retest to closure: re-verify every fix. A report full of open findings is a to-do list; a report with retest evidence is proof — and it is what regulators and enterprise customers actually ask for.
Where it meets Indian regulation
Testing is not an end in itself here — it is evidence for a specific obligation:
- CERT-In: empanelled security testing underpins the "safe to host" confirmations that government tenders and many enterprises require, and sits alongside the six-hour incident-reporting direction. Who runs the test matters — empanelment is often the gate.
- RBI: regulated entities must test internet-facing and critical systems, with closure evidence rather than an open-findings list, as part of their IS-audit and cyber-security framework obligations.
- SEBI (CSCRF): registered intermediaries need VAPT within a defined framework, with secure-SDLC and change-management controls that make testing recurring, not one-off.
- DPDP Act, 2023: data fiduciaries must take reasonable security safeguards. A documented, closed-out penetration test is among the clearest ways to evidence that the safeguards are real and not just written down.
What to demand from whoever tests you
The questions that separate a real provider from a scan-and-ship one are simple, and the answers are revealing:
- Is the testing grey-box across roles, or black-box only? If authenticated testing is not in scope, your highest-impact surface is not being tested.
- Is retest included? Fixing findings is the point; a provider who does not retest is not finishing the job.
- Who signs the report, and are they CERT-In empanelled where you need it? Empanelment is frequently the difference between a report a regulator or tender will accept and one they will not.
- Will findings come with reproduction steps and real business impact, or just a tool's severity label? You cannot fix — or prioritise — what you cannot reproduce.
- Does the methodology follow the OWASP WSTG, and does it cover the APIs behind the UI, not just the browser-facing pages?
The tools — and why they are not the test
Good testers use tools heavily; they just do not confuse them with the test. Scanners widen coverage and catch the obvious; the tester supplies the judgement the scanner cannot.
| Tool | What it does well | What it cannot do |
|---|---|---|
| Burp Suite | Intercepting proxy for manual testing; the workhorse for authenticated, logic and injection testing | Decide what should be allowed — judgement is the tester's |
| OWASP ZAP | Open-source proxy and scanner; good for CI/CD baseline checks | Find business-logic and access-control flaws |
| Nuclei | Fast, templated checks for known CVEs and misconfigurations at scale | Chain findings into real exploitation |
| sqlmap | Confirm and exploit SQL injection once a candidate is found | Find the candidate in parameterised or second-order cases |
| Automated DAST scanners | Breadth and regular regression coverage | Authenticated, multi-role and logic testing — i.e. the serious findings |
Frequently asked questions
FAQs
What is the difference between a penetration test and a vulnerability scan?
A scan automatically checks for known, catalogued issues and returns a list. A penetration test uses that output as a starting point, then has a human probe authentication, access control and business logic to find and prove the flaws that cause real breaches — the ones scanners cannot see. If a "pentest" report has no business-logic or access-control findings, it was almost certainly a scan.
Black-box or grey-box — which should I ask for?
Grey-box, with accounts across your real user roles, for almost every web app. Most damaging attacks start from an authenticated session, so black-box-only testing leaves the highest-impact surface untested. Black-box has its place for an external-attacker view, but it should not be the whole engagement.
How often should we test?
At least annually, and after any significant change — a new release, a new integration, a re-architecture, or a move to a new cloud environment. Regulated entities (RBI, SEBI, PCI DSS) often have their own frequency requirements, and a material change resets the clock regardless.
Does the test satisfy our CERT-In / RBI / DPDP obligations?
It is a core part of the evidence, provided it is run by an appropriately empanelled firm, covers the right scope, and closes findings with retest evidence. An open-findings report rarely satisfies an auditor; a closed-out one usually does. For CERT-In-gated use (tenders, safe-to-host), empanelment of the testing firm is typically mandatory.
How do we prepare?
Define scope precisely — every role, every sensitive workflow, and the APIs behind the UI. Provide test accounts for each role so grey-box testing is possible, a stable test environment, and a technical point of contact. The single biggest driver of a useful test is scope defined well up front.
The bottom line
A web application penetration test is worth what it finds, and what it finds depends on whether a person tested your application or a tool scanned it. Insist on authenticated, multi-role testing against the OWASP WSTG, reproduction steps and business impact on every finding, and a retest that proves the fixes landed. CyberSigma runs CERT-In empanelled web application VAPT on exactly that basis — senior testers, audit-ready reports, retest to closure. If you want a straight read on your current scope and the fastest path to a clean result, book a free scope review.
Liked the post? Share on:
Leave A Comment