A web application penetration test is a short, time-boxed engagement. If the testers spend the first two days waiting for a working login, chasing a staging server that does not match production, or asking who owns the admin panel, that time comes out of the testing itself. The report you get back is thinner, and it may say nothing about the parts of the application that matter most.
This guide covers what to decide and hand over before day one: the scope, the test accounts, the environment, the rules of engagement and the people who need to be available. Use it as a readiness checklist a week or two before your test starts.
Quick answer: Write down the exact scope (URLs, APIs, user roles and what is off limits), create at least two test accounts for every role, pick staging or production and make sure it runs the live version, switch payments to sandbox mode, agree test windows and emergency contacts in writing, take a backup and name one developer who can answer questions during the test.
Fix the scope in writing
The scope decides what the report can tell you. If the admin panel or the partner API is not listed, it will not be tested, and a clean report will say nothing about it. Before you ask for a quote, list the following:
- Hostnames and URLs: the main application, admin panel, customer portal, API base URLs and any subdomains that serve the same product.
- User roles: every type of user, such as customer, staff, branch manager, finance approver and super admin, and what each one should and should not be able to do.
- Key workflows: sign-up, login and OTP, password reset, checkout, refunds, approvals, file uploads and report downloads.
- Integrations: payment gateway, SMS and email providers, file storage, single sign-on and any webhooks the application receives.
- Out of scope: third-party systems you do not own (the gateway's hosted checkout page, for example), denial-of-service testing, social engineering and any live data that must not be touched.
If you are unsure what a full test covers, our web application VAPT audit guide walks through the areas, and the web application VAPT service page lists what is included in each engagement.
Create test accounts: two per role, across two tenants
Broken access control is ranked first in the OWASP Top 10 (2021 edition), and it is found by comparison. A tester logs in as customer A, captures the request that loads an invoice, then replays it as customer B. If B can see A's invoice, that is an insecure direct object reference (IDOR). With only one account per role, this kind of check cannot be done properly.
- Two accounts for every role, so access between users at the same level can be tested.
- Two tenants or companies if your product is multi-tenant SaaS, each with its own admin and regular user, so tenant isolation can be checked.
- Realistic sample data in each account: orders, invoices, uploaded documents and messages. An empty account gives testers nothing to try to reach.
- A clear OTP route: test phone numbers or inboxes the testers can receive codes on. If staging skips OTP, say so, because that changes what can be tested.
- Accounts that can be broken: testers may lock, reset or change these accounts, so never hand over a real staff login.
Choose the environment: staging or production
Both options work if you understand the trade-off. Staging protects live data; production shows exactly what an attacker sees. What matters most is that the environment runs the same code version and configuration as the live system.
| Question | Staging | Production |
|---|---|---|
| Risk to live data and users | Low, test data only | Needs care: backups, off-peak windows, no destructive tests |
| Accuracy of findings | Good only if code, configuration and firewall settings match production | Highest, because it is the real system |
| Payment testing | Gateway test mode with test keys | Only agreed, low-value transactions that you can refund |
| Usual fit | First tests, sensitive data, fragile systems | Mature applications with tested backups, or where no staging exists |
Two practical points. First, Razorpay, Cashfree and PayU all provide test or sandbox modes, so amount and order tampering checks can run without real money. Second, decide in advance whether your web application firewall (WAF) or CDN will allowlist the testers' IP addresses. Testing with the WAF on shows real-world exposure; allowlisting shows flaws in the application itself. Many teams run the main test with an allowlist and a short check with the WAF active.
Do not copy real customer data into staging for the test. If you have to, mask it first. Personal data in a test environment is still personal data under the DPDP Act.
Agree the rules of engagement in writing
Rules of engagement protect both sides. They make the test authorised, predictable and easy to stop if something goes wrong. Put these in a signed document before testing starts:
- Written authorisation from someone who owns or controls the systems, plus an NDA, ideally signed before scoping.
- Test dates, daily time windows in IST and blackout periods such as month-end billing or a sale.
- The IP addresses the testers will use, so your team can recognise the traffic.
- Activities that are not allowed, such as denial-of-service, deleting data or contacting your staff.
- Emergency contacts on both sides and a stop procedure if the application slows down.
- How critical findings are reported during the test, rather than waiting for the final report.
- How evidence containing personal data is stored, and when it is deleted.
If your application runs on shared hosting or a cloud platform, read the provider's penetration testing policy. Major cloud providers let customers test their own resources on most services without advance notice but prohibit some activities, such as denial-of-service tests. Smaller hosting companies may want to be told first.
Documents and people that make the test faster
- A short architecture note: front end, back end, database, queues, file storage and third-party services.
- API documentation: an OpenAPI file or Postman collection, even if it is slightly out of date.
- A workflow walkthrough: a short call where a product owner shows the key flows and where money or sensitive data moves.
- Previous reports and known issues, so testers do not spend time rediscovering them.
- A named developer who can reset accounts, check logs and answer questions during the test window.
Sharing documentation and test accounts makes the test a grey-box assessment, which suits most business applications. For critical systems, adding code access through a source code security audit finds more in the same time.
Mistakes that weaken the report
- One shared admin account instead of separate accounts for each role.
- Deploying new code mid-test, so findings cannot be reproduced and testers chase a moving target.
- A WAF that silently blocks the testers on day one, with nobody available to allowlist them.
- Forgotten assets such as an old admin panel on a separate subdomain or a v1 API still used by an older mobile app.
- No owner for critical findings, so an urgent issue waits in an inbox until the final report arrives.
How EthicsComputer can help
Our web application VAPT starts with a mutual NDA and a written scope covering assets, roles, test windows and rules of engagement. Testing follows the OWASP Web Security Testing Guide; most web applications are typically tested in 5 to 10 working days, and critical issues are typically reported within 24 hours. If your application also serves mobile apps or partners, we can include API security testing in the same scope.
Not sure what belongs in the scope of your first test?
Send us your application URLs, user roles and target dates, and we will help you turn them into a clear, written test scope.
About the author
Vinay Grover founded EthicsComputer in Rohtak, Haryana in 2018 and leads its cybersecurity, software and AI work for clients across India and abroad. EthicsComputer is ISO 9001, ISO/IEC 27001 and ISO 20000-1 certified.
