Web application penetration testing is a controlled, manual attack on your web application by a security tester, done with your permission, to find and prove the flaws a real attacker could use. The tester logs in as different users, tampers with requests, abuses business flows and chains small weaknesses together, then gives you a report with evidence, severity and fixes for each issue.
If you need a pentest before a client security review, an audit or a launch, this guide covers what to expect: how it differs from automated scanning, the step-by-step methodology based on the OWASP Web Security Testing Guide, a checklist mapped to the OWASP Top 10, the findings that most often turn up, how to prepare, and what a good report should contain.
Key takeaways
- A scanner finds known patterns; a manual pentest finds access control, logic and authentication flaws that scanners cannot reason about.
- Grey box testing with test accounts for every user role usually gives the best value for the time and money spent.
- A sound methodology follows OWASP WSTG v4.2: scoping, recon, authentication and sessions, access control, injection, business logic, file upload, configuration, client-side, reporting and retest.
- IDOR, weak OTP and password reset flows, payment logic flaws, exposed admin panels and public cloud storage are among the most common high-impact findings.
- Prepare a stable staging environment, role-wise test accounts, realistic data and a clear scope list before testing starts.
- The report should give proof, CVSS-based severity, business impact and step-by-step fixes, followed by a retest.
What is web application penetration testing?
Web app penetration testing (often shortened to web app pentesting) is one part of VAPT, or Vulnerability Assessment and Penetration Testing. The assessment part finds and lists weaknesses broadly, largely with tools. The penetration testing part tries to exploit them to show real impact. If you are new to the term, our explainer on what VAPT is covers the basics.
Website penetration testing applies to anything your users reach through a browser: customer portals, SaaS dashboards, admin consoles, checkout flows and internal tools exposed to the internet. Most modern web apps also sit on top of APIs, so the test usually covers the API calls the front end makes. If your platform is API-first or exposes public APIs to partners, plan a dedicated API security test as well.
Manual pentesting vs automated scanning
Scanners such as OWASP ZAP or Burp Suite's scanner quickly flag missing headers, outdated libraries and common misconfigurations. But a scanner does not understand that user A should never see user B's invoice, or that a coupon should not work twice. Those flaws cause data leaks and fraud.
| Aspect | Automated scanning | Manual penetration testing |
|---|---|---|
| How it works | Sends known payloads and matches responses to signatures | A tester studies the app, forms hypotheses and attacks it like an adversary |
| Strong at | Headers, TLS, known CVEs, obvious injection, outdated components | Access control, IDOR, business logic, auth flows, chained attacks |
| Weak at | Multi-step flows, role-based authorisation, logic abuse | Breadth across very large estates in a short time |
| False positives | Common; needs triage | Low; every finding is verified with proof |
The sensible approach is both: run scanners in your pipeline for continuous hygiene, and commission manual testing before major releases, client reviews and audits.
Black box, grey box and white box testing
These terms describe how much the tester knows before starting.
- Black box: no credentials or documentation. It simulates an outsider, but much of the time goes into discovery, and features behind the login get little attention.
- Grey box: the tester gets test accounts, a walkthrough of key flows and sometimes API documentation.
- White box: full access to source code and architecture; the most thorough option for high-risk applications.
Why grey box with role-wise test accounts gives the best value
Most serious web app flaws live behind the login, in how the application decides who can do what. To test that, the tester needs two accounts per role (to try reaching one user's data from another) across every privilege level: customer, staff, admin, and separate tenants if your app is multi-tenant. You get deeper coverage for the same effort, focused on where broken access control actually hides.
Web application security testing methodology (OWASP WSTG v4.2)
OWASP penetration testing usually means following the OWASP Web Security Testing Guide (WSTG), whose current stable version is v4.2, and mapping findings to the OWASP Top 10. A thorough process for penetration testing on web application targets looks like this.
- Scoping and rules of engagement. Agree on URLs, environments, roles, out-of-scope features, testing windows and whether destructive tests are allowed. Written authorisation comes first.
- Reconnaissance and mapping. Identify technologies, subdomains, open ports (for example with Nmap), hidden paths and API endpoints, and map every page, parameter and role through a proxy such as Burp Suite.
- Authentication and sessions. Login, OTP, password reset, MFA, lockout and rate limiting; token randomness, cookie flags, expiry, logout and JWT validation.
- Authorisation and access control. Horizontal access (user A reaching user B's records, known as IDOR), vertical access (a normal user calling admin functions) and tenant isolation.
- Input validation and injection. SQL and NoSQL injection, command and template injection, cross-site scripting (XSS), XXE and server-side request forgery (SSRF).
- Business logic. Price tampering, coupon and wallet abuse, skipped workflow steps, race conditions and approval bypass.
- File upload. Type checks, executable uploads, path traversal and whether uploaded files are publicly reachable.
- Configuration. TLS, security headers, CORS, verbose errors, default credentials, exposed admin or debug panels and cloud storage permissions.
- Client-side testing. DOM-based XSS, secrets in JavaScript bundles, clickjacking and sensitive data stored in the browser.
- Reporting. Each finding verified, rated and written up with reproduction steps, evidence and fixes.
- Retest. After your team fixes the issues, the tester confirms each fix and updates the report.
Need a manual, OWASP-aligned test before a client review or launch? See how our web application penetration testing service works, including role-wise grey box testing and a free retest.
Web application penetration testing checklist
Use this web application penetration testing checklist to check a vendor's coverage, or as a web application security testing checklist for your own team before an external test. It is grouped by area and is a starting point, not an exhaustive list.
Authentication and sessions
- OTP and login endpoints are rate limited; OTPs expire, are single-use and tied to the right user.
- Password reset tokens are random, short-lived and single-use.
- Session cookies use Secure, HttpOnly and SameSite; sessions end on logout and password change.
- JWT signatures, algorithm and expiry are enforced server-side.
Access control
- Every object ID (order, invoice, document) is checked against the logged-in user on the server.
- Admin functions reject non-admin users even when called directly; tenants cannot reach each other's data.
Input, files and business logic
- Inputs are validated server-side, queries parameterised and output encoded.
- Uploads are restricted by type and size, renamed and stored outside the web root.
- Prices and totals are calculated on the server; one-time actions are safe against parallel requests.
Configuration and client-side
- TLS is current; HSTS, Content-Security-Policy and X-Frame-Options are set; CORS allows only trusted origins.
- Errors do not leak stack traces; no secrets in JavaScript bundles; libraries are up to date.
- Logins, failed access and admin actions are logged and alerted on.
Checklist mapped to OWASP Top 10 (2021)
| OWASP Top 10 (2021) | What the tester checks |
|---|---|
| A01 Broken Access Control | IDOR, privilege escalation, tenant isolation, forced browsing to admin pages |
| A02 Cryptographic Failures | TLS configuration, sensitive data in transit and at rest, weak password hashing |
| A03 Injection | SQL, NoSQL, OS command and template injection, and XSS |
| A04 Insecure Design | Business logic flaws, missing limits on sensitive flows, workflow bypass |
| A05 Security Misconfiguration | Headers, CORS, verbose errors, default accounts, open cloud storage, debug panels |
| A06 Vulnerable and Outdated Components | Known CVEs in frameworks, plugins and JavaScript libraries |
| A07 Identification and Authentication Failures | OTP and reset flows, brute force protection, session handling, MFA bypass |
| A08 Software and Data Integrity Failures | Unsafe deserialisation, unsigned updates, untrusted third-party scripts |
| A09 Security Logging and Monitoring Failures | Whether attacks during testing were logged and would trigger alerts |
| A10 Server-Side Request Forgery | URL fetch features, webhooks and import functions reaching internal or cloud metadata services |
OWASP has since published a 2025 edition; check which edition your reviewer expects.
Common high-impact findings in Indian web apps
These patterns recur across SaaS, fintech, e-commerce and enterprise apps, usually because teams assume the front end will enforce the rules.
- IDOR (insecure direct object references). Changing an order, customer or document ID in a request returns another user's data, which is serious in apps holding KYC documents or invoices.
- Broken OTP and password reset flows. No rate limit, OTPs returned in the API response, checks done only in the browser, or reset links that never expire, any of which can lead to account takeover.
- Payment and business logic flaws. Amount tampering before the gateway call, trusting a client-side "payment success" callback, or reusing coupons and racing refund requests.
- Exposed admin panels. Admin consoles or dashboards reachable from the internet, sometimes with weak credentials and no MFA.
- Misconfigured S3 buckets and cloud storage. Buckets that allow public listing or reads, exposing uploads, backups or exports.
How to prepare for a web app pentest
Good preparation saves testing time and gives you better results for the same budget.
- Staging environment: a stable copy of production with the same code and configuration. Avoid deploying new builds mid-test unless agreed.
- Test accounts per role: at least two accounts for each role and, for multi-tenant apps, accounts in two separate tenants.
- Realistic test data: enough records, orders and documents for flows to work, without real customer data.
- Scope list: URLs, subdomains, API base paths, roles, key features, and anything explicitly out of scope.
- Whitelisting: allow the tester's IP addresses through your WAF, rate limiting and geo-blocking so you test the application, not the firewall.
- Third parties and contact: put payment gateways and SMS providers in sandbox mode, and name one engineer who can answer questions quickly.
What a good pentest report should contain
Your client or auditor will read the report, so ask for a sample before hiring. It should include:
- An executive summary in plain language, with overall risk and the top issues.
- Scope, approach, testing dates and tools used.
- Each finding with its OWASP mapping, a severity rating (commonly CVSS v3.1), affected URLs, step-by-step reproduction, screenshots or request evidence, and business impact.
- Clear, step-by-step remediation that your developers can act on, not generic advice.
- A retest section or updated report showing which issues are fixed and verified.
Some regulators and enterprise clients ask for a CERT-In-empanelled auditor. Check your requirement before you shortlist vendors, and confirm the report format your reviewer expects.
How much does web application penetration testing cost?
Cost depends on the number of roles, modules and user flows, whether APIs are included, the testing approach, and any compliance format required. At Xtreme InfoSec, web application penetration testing starts from ₹30,000, and the final price is a fixed quote after scoping. Timelines also depend on scope and are confirmed in the quote.
For a quick indication, use our VAPT cost estimator. For a detailed look at what drives pricing and what to ask vendors, read our guide to penetration testing cost.
Frequently asked questions
What is the difference between web application penetration testing and vulnerability scanning?
A vulnerability scan is automated and checks for known issues such as outdated software and missing headers. Web application penetration testing is manual: a tester actively tries to exploit the app, including access control and business logic flaws that scanners cannot detect. Most audits and client reviews expect a manual pentest report.
How often should a web application be pentested?
At least once a year, and after any major release, new payment or authentication flow, or architecture change. Enterprise clients and regulators may set their own frequency, so check your contract or circular.
Can penetration testing be done on the production environment?
It can, but staging is safer for intrusive tests such as injection and business logic abuse. If production must be tested, agree on testing windows, avoid destructive tests and keep backups ready.
Is the OWASP Top 10 enough for a web app pentest?
The OWASP Top 10 is an awareness list of the most critical risk categories, not a full test plan. A thorough test follows the OWASP Web Security Testing Guide and maps findings to the Top 10 for reporting. Business logic testing specific to your app matters just as much.
What happens after the pentest report is delivered?
Your developers fix the issues using the remediation steps, starting with critical and high severity findings. The tester then retests each fix and issues an updated report showing which findings are closed. That updated report is usually what you share with clients or auditors.
Get your web application tested before the review
Xtreme InfoSec runs manual, expert-led web application penetration testing with role-wise grey box coverage, an OWASP-mapped report with step-by-step fixes, and a free retest after you fix the issues. Share your scope and we will send a fixed quote.