Web Application VAPT: Scope, Steps and Report Explained

Last updated: 28 October 2026. Sources are listed at the end.

A web application VAPT is a security test of your website, portal or web app. Testers try to break it the way an attacker would. Most Indian businesses buy their first one because a client, an ISO 27001 auditor, a bank partner or a regulator asked for it. As a result, many owners sign a quote without knowing what they should get.

This guide is for SMB owners and CTOs in that position. It explains the scope, the steps and the report. It also covers preparation, cost factors and when you need a CERT-In empanelled auditor.

The short answer

VA (vulnerability assessment) finds and lists weaknesses. PT (penetration testing) proves which ones an attacker can actually use.
A good web application VAPT tests login, sessions, access control, input handling, APIs, business logic and server configuration. It maps findings to the OWASP Top 10:2025 and uses the OWASP testing guide as a method.
Expect a scoping call, written authorisation, a testing window, a report and then a re-test after your fixes.
The report should rate each finding (CVSS v4.0 or v3.1), show evidence, give reproduction steps and explain the fix.
If someone asks for a CERT-In empanelled auditor, check the firm on CERT-In’s published list before you sign.
A scanner printout with your logo on it is not a VAPT.

VA vs PT: what is the difference?

A vulnerability assessment is broad. The tester runs scanners and quick manual checks to list everything that looks weak. Typical items are an outdated library, a missing header or an old TLS version. Some items on that list may be false alarms.

Penetration testing goes deeper on fewer items. The tester tries to exploit a weakness, within agreed limits, to show the real impact. For example, a scanner might flag “possible IDOR”. A pentester logs in as customer A, changes an ID in the request and shows that customer B’s invoice opens.

A web application VAPT combines both. The VA part gives coverage, and the PT part gives proof and priority. For how an assessment differs from a formal audit, see our post on the difference between assessment and audit.

Black box, grey box and white box

These terms describe how much the tester knows before starting.

Approach	What the tester gets	Good for	Trade-off
Black box	Only the URL	Seeing what an outsider sees	Misses most logic behind the login
Grey box	URL plus test accounts for each role	Most business apps	Needs you to create and share accounts
White box	Accounts plus source code, architecture docs	Critical apps, fintech, health data	More effort and cost

For most SMB apps, grey box gives the best value. Most serious bugs sit behind the login page. A tester without accounts spends the budget knocking on the front door.

What a web application VAPT covers

The scope should list the areas below, and each finding should map to a known category.

OWASP released the 2025 edition of its Top 10 in late 2025. It is an awareness list, and OWASP never meant it as a full test plan. CERT-In’s July 2025 audit guidelines agree: such lists should not be the audit standard on their own. Instead, testers should follow the OWASP Web Security Testing Guide (WSTG) and the Application Security Verification Standard (ASVS).

Area tested	What the tester checks	OWASP Top 10:2025 category
Authentication	Password rules, brute-force limits, OTP and MFA bypass, reset flows	A07 Authentication Failures
Sessions	Cookie flags, logout, session fixation, token expiry	A07 Authentication Failures
Access control	Reading another user’s data, admin pages open to normal users	A01 Broken Access Control
Input handling	SQL injection, XSS, command injection, file upload abuse	A05 Injection
APIs	Missing auth on endpoints, too much data in responses, mass assignment	A01, A05 and others
Business logic	Changing a price, skipping a payment step, reusing a coupon	A06 Insecure Design
Config, TLS and headers	Default pages, verbose errors, weak TLS, missing HSTS or CSP	A02 Security Misconfiguration, A04 Cryptographic Failures
Components	Outdated libraries and plugins with known CVEs	A03 Software Supply Chain Failures
Errors and logging	Stack traces shown to users, unsafe failures, no alerts	A10 Mishandling of Exceptional Conditions, A09 Security Logging and Alerting Failures

A08 (Software or Data Integrity Failures) applies when an app trusts unsigned updates or serialized data. The report should say which categories applied to your app.

The phases of a web application VAPT

Step 1: Scoping and rules of engagement

First, both sides agree on what is tested, when, from where and what is off limits. Both sign this before testing starts. Here is an illustrative rules-of-engagement table with example values:

Item	Example entry
In scope	`https://staging.example.in`, `https://api-staging.example.in/v2/`
Out of scope	Payment gateway pages, third-party chat widget, email servers
Approach	Grey box, 3 roles: customer, branch manager, admin
Environment	Staging, with a copy of production config and masked data
Testing window	10 to 21 November, 10:00 to 19:00 IST
Source IPs	Tester’s fixed IPs, allow-listed on the WAF
Not allowed	Denial-of-service tests, social engineering, deleting data
Stop rule	Tester pauses and calls the client if a critical issue or outage appears

Step 2: Reconnaissance

Next, the tester maps pages, parameters, API endpoints, subdomains and exposed ports. Port discovery often uses Nmap, covered in our Nmap scans for network admins post.

Step 3: Automated scanning

Then scanners crawl the app for common issues. They give coverage, but they miss logic flaws and produce false positives. So treat the scan output as input for the manual work that follows.

Step 4: Manual testing

Most of the value sits here. The tester works through each role and tries to cross role boundaries. They also tamper with requests in a proxy and walk through business flows by hand. Access control and logic bugs usually turn up at this stage.

Step 5: Exploitation within limits

The tester proves a real weakness with the least harmful method, for example by reading one test record instead of dumping a table. Anything risky, such as heavy load or destructive actions, needs written approval first. CERT-In’s audit guidelines also require written permission before any DoS or DDoS testing.

Step 6: Reporting

After testing, the tester writes up each finding with evidence and fix guidance. Critical issues should reach you by phone or email as soon as they are found, well before the final report.

Step 7: Remediation and re-test

Finally, your team fixes the issues and the tester checks each fix. Ask for the re-test in the original quote. CERT-In’s guidelines also expect a follow-up audit after closure. Unresolved items become repeat observations in the next cycle.

What a good web application VAPT report contains

A useful report serves two readers. Management needs risk in plain words, and developers need enough detail to fix things. Check for these parts:

An executive summary with the overall risk, counts by severity and the top issues in plain English.
Scope, dates, approach and environment.
A severity score for each finding, using CVSS v4.0 or v3.1, with the vector string. CERT-In’s guidelines also ask for EPSS, which estimates the chance a CVE gets exploited.
Evidence: requests, responses and screenshots.
Step-by-step reproduction, so your developer can see the bug themselves.
Fix guidance written for your stack.
Re-test status per finding: open, fixed or risk accepted.

Here is an illustrative sample finding. It is not from a real client.

Field	Example
Title	Customer can view other customers’ invoices (IDOR)
Severity	High. CVSS v4.0 vector and score included in the full report
Affected	`GET /api/v2/invoices/{id}`
Category	OWASP A01:2025 Broken Access Control
Steps	1. Log in as test customer A. 2. Open own invoice 10452. 3. Change the ID to 10453. 4. Invoice of customer B loads.
Impact	Any customer can read other customers’ names, addresses and amounts
Fix	Check on the server that the invoice belongs to the logged-in user before returning it. Do not rely on hidden IDs.
Re-test	Fixed on 28 November. Request with another user’s ID now returns 404

You can confirm some config findings yourself. For example, this command shows which security headers a server sends. We tested it on Ubuntu 24.04 (curl 8.5.0) against a local nginx 1.24 test server.

curl -sI https://your-site.example/ | grep -iE '^(server|strict-transport-security|content-security-policy|x-content-type-options|x-frame-options):'

On our lab server it printed two lines. So HSTS, CSP and frame protection were missing, and the version number was visible:

Server: nginx/1.24.0 (Ubuntu)
X-Content-Type-Options: nosniff

Our secure Nginx configuration post shows how to fix those.

How to prepare as a client

Sort out these items before your web application VAPT window opens:

Written authorisation signed by someone who owns the system. If the app is hosted with a provider, check their testing policy too.
Two test accounts for each role, so the tester can try cross-user access.
A decision on staging or production. Staging is safer but must match production. Testing on prod needs backups and no destructive tests.
Fresh backups of the database and files before testing starts.
WAF and rate-limit allow-listing for the tester’s IPs, so the test reaches the app itself.
Named points of contact on both sides who answer the phone during the window.
API documentation or a Postman collection, if APIs are in scope.

Timelines and what affects cost

Prices depend on the app, so we do not quote them here. However, these factors drive the effort, and so the cost:

Size of the app: number of pages, user roles and API endpoints.
Approach: black, grey or white box. Code review adds effort.
Complexity of business logic, such as payments, approvals and multi-tenant data.
Environment: production testing needs slower, more careful work.
Report needs: a CERT-In empanelled audit certificate or a regulator format.
Number of re-tests included.

A small marketing site often needs only a few days of testing. A portal with several roles and an API often needs one to three weeks, plus reporting time. Ask the tester for an effort estimate in person-days so you can compare quotes fairly.

CERT-In empanelled auditors: when do you need one?

CERT-In empanels information security auditing organisations after a selection process that includes technical tests. Empanelment applies to the organisation for a set period, and CERT-In publishes the current list. The firm must use staff it has declared to CERT-In, not freelancers or interns.

You need an empanelled auditor when a contract, tender, government project or sectoral regulator says so. SEBI and RBI set their own audit rules, so regulated entities should read the exact circular that applies to them. For other businesses, an empanelled auditor is a choice.

CERT-In published its Comprehensive Cyber Security Audit Policy Guidelines (version 1.0) on 25 July 2025. They say organisations should audit their ICT systems at least once a year, and regulators may ask for more. They also discourage tool-only testing. In addition, auditees should verify the identity and credentials of the auditors who turn up.

How often should you test?

Run a full web application VAPT at least once a year. Also test after any major change, such as a new login system, a payment flow or a move to new hosting. Many teams run a lighter scan monthly or on each release. Then they keep the full manual test for the yearly cycle and big changes. If a contract or regulator sets a frequency, follow that.

Common mistakes to avoid

Buying a scanning-only “VAPT”. If the quote has no person-days of manual testing and no test accounts, it is a scan.
Skipping the re-test. Without it, you have a list of problems and no proof they were fixed.
Testing the wrong environment. A staging server with different code or config gives a clean report for an app nobody uses.
Leaving APIs out of scope. Mobile apps and single-page apps usually expose the real logic through APIs.
Treating the report as a lasting certificate. It describes one version of the app on certain dates.

For what auditors check beyond the app, see our post on auditing web servers and web applications.

Quick checklist

☐ Decided between VA only, or VA plus PT, and black, grey or white box
☐ Scope lists URLs, APIs, roles and what is out of scope
☐ Rules of engagement and written authorisation signed
☐ Staging vs production decided, and backups taken
☐ Two test accounts per role created
☐ Tester IPs allow-listed on the WAF and rate limits
☐ Points of contact and testing window agreed
☐ Quote includes manual testing person-days and at least one re-test
☐ Report will include CVSS ratings, evidence, reproduction steps and fixes
☐ CERT-In empanelment checked on the official list, if required

If you want a tester to scope this with you, our VAPT service covers web apps and APIs with a re-test included. You can also run our free website safety check first to see the basic issues before you book.

Sources

Need help finding and fixing exposed systems? Our VAPT services find unpatched and exposed systems before attackers do, and our free website safety check grades your site in seconds. Contact us for a quote.

The short answer