Web application penetration testing
Our engineers test your customer-facing apps, internal portals and admin consoles by hand, signed in as every role and signed out, then write a report your developers can fix from. Based in Hyderabad, testing for companies across India.
- Approach
- Grey-box by default
- Baseline
- OWASP Top 10, ASVS L2/3
- Duration
- 5 to 10 working days
- Logins and roles from
- INR 27,000 + 18% GST
Last reviewed
| Function | Customer | Staff | Admin |
|---|---|---|---|
| View own invoices | Allowed, as designed | Allowed, as designed | Allowed, as designed |
| View another customer's invoice | Finding: allowed, but should be refused | Refused, as designed | Refused, as designed |
| Approve a discount | Refused, as designed | Refused, as designed | Allowed, as designed |
| Open admin settings | Refused, as designed | Refused, as designed | Allowed, as designed |
| Export all customer data | Refused, as designed | Refused, as designed | Allowed, as designed |
- CustomerView another customer's invoice: allowed, but should be refused
01 / Who needs it
Who needs web application penetration testing
If people sign in to something your company built, and what sits behind that sign-in is worth stealing, it needs a penetration test. A scanner can tell you that a security header is missing. It cannot tell you that a sales user can open another company's invoices by changing a number in a request, or that the discount approval step can be skipped.
That gap is what this service covers: an engineer testing your customer-facing applications, internal portals and admin consoles by hand, the way an attacker would, both signed in and signed out.
The teams that ask us for a web application test are usually in one of these positions:
About to launch
A test before release is the cheapest point to find a serious flaw, because the cheapest critical to fix is the one that never reached production.
Selling to larger customers
Enterprise security questionnaires ask about tenant isolation, single sign-on and admin access. A recent test that covers those areas gives you evidence to answer with.
Running a multi-tenant SaaS platform
One tenant's data must never be visible to another, and the admin console is the most valuable target in the system.
Working through an audit
Security and privacy programs such as SOC 2, ISO 27001, PCI DSS and the DPDP Act often raise the question of whether your applications have been tested. The compliance section below explains how the report fits.
Unhappy with the last report
If your previous test arrived as a long tool export with severity bars and no fixes, the difference here is a write-up with reproduction steps and a code-level fix for each finding.
Where BERRY9 began
Web portals are where BERRY9 began: the first engagement after the company was registered in Hyderabad in 2015 was testing an EdTech company's web portals.
02 / What we test
Eight areas, tested within the agreed scope
Grey-box testing is the default. You give us test credentials for each role and we work from there, which lets us spend the time on what each kind of user can and cannot do, rather than on getting past the login page.
OWASP Top 10 and ASVS Level 2/3 controls
This is the floor, not the ceiling. The OWASP Top 10 names the categories of weakness every web test has to address, and the OWASP Application Security Verification Standard (ASVS) breaks them into specific controls that can be checked one by one. The report carries a per-category coverage matrix, so an auditor or a customer's security team can see the ground that was covered, not only the findings.
Authorization boundaries — IDOR, privilege escalation, tenant isolation
Whether the application stops people doing what their role does not allow. Can a read-only user edit? Can an ordinary user reach an admin function by calling it directly instead of through the menu? Can one customer open another customer's records? This is where the most serious web findings usually sit, so it gets a dedicated phase, tested as several users across roles and tenants.
Authentication, session, and SSO integrity
Sign-in, sign-out, password reset, remember-me tokens and single sign-on handoffs. We check whether a session really ends when it should, whether a token such as a JWT can be altered or replayed, and whether the reset flow can be turned against the person it is meant to help.
Business-logic flaws unique to your domain
Flaws in how your rules are enforced rather than in how the code is written: an approval step that can be skipped, an order total that can still change after approval, a one-time benefit that can be claimed twice. No scanner knows your business rules, so an engineer walks every state transition by hand.
Injection — SQL, NoSQL, command, template, XXE
Input that reaches a database query, an operating system command, a template engine or an XML parser without being handled safely. Current frameworks close the obvious paths, so the effort goes into the places they do not cover; the common findings below give examples.
Server-side request forgery, deserialization, file uploads
Features that make your server fetch a web address, rebuild an object from data a user sent, or store a file from the outside world. Each one is convenient for users and, when it trusts its input too much, a route to internal systems or to code running on your server.
Client-side — XSS, CSRF, prototype pollution, postMessage
Weaknesses that play out in the user's browser: injected script (XSS), requests forged from another site (CSRF), prototype pollution in JavaScript objects, and careless messaging between windows and frames. Single-page applications move much of their logic into the browser, so this part of the test has grown with them.
Race conditions, rate-limit and quota abuse
What happens when the same request arrives many times at once, or thousands of times in a minute. Double redemptions, balances updated twice, guessable one-time codes and plan limits that can be exceeded all belong here, and none of them shows up when a page is tested one click at a time.
APIs have a service of their own: see API security testing.
03 / Method
How the test runs
A web application test moves through five phases. The order is the same on every web application test; the time spent in each depends on how large and how complex your application is.
Show details for How the test runs
Phase 1 · Day zero
Scope and threat model
Before any testing, we agree in writing the assets in scope, the boundaries, the rules of engagement and the threat model: what an attacker would go after in your application, what we may demonstrate impact against, and what is a hard stop. For a web application this means the URLs, the roles and their test accounts, third-party services that must not be touched, and the limits on active testing.
OutputRules of engagement and threat model
Phase 2
Reconnaissance and surface mapping
Passive and active enumeration of every endpoint the application exposes, including the ones missing from your documentation, such as forgotten admin endpoints or older versions of a route that are still answering. The aim is to have no surprises once testing starts.
OutputEndpoint inventory
Phase 3
Manual-led discovery
An authenticated and unauthenticated walk through every input, every role and every authorization boundary. Scanners run in parallel for coverage, and they find some things faster, but the work is driven by an engineer. The high-severity findings, the chained criticals and the business-logic flaws come from human work, not tool output.
OutputCandidate findings
Phase 4
Exploitation and chaining
Each finding worth reporting is validated with a proof of concept. Single findings are demonstrated; chained findings are walked end to end. Testing is kept safe: we avoid disrupting production, and the rules of engagement set what is a hard stop.
OutputProofs of concept
Phase 5
Reporting
An engineer-grade report with reproductions, the payloads used and code-level fixes, described in the next sections. Once your team has patched, the retest follows the terms set out further down this page.
OutputExecutive and engineering reports
Our general approach is described on the VAPT methodology page.
04 / Common findings
Common findings in web applications
Four kinds of finding come up again and again in our web application reports. Each one is described here in terms of what it means for your business; the report itself carries the technical detail your developers need.
Show details for Common findings in web applications
| Finding | What happens | Severity | What your developers get |
|---|---|---|---|
| Insecure Direct Object Reference (IDOR) | An endpoint accepts an object ID, such as an invoice number or a customer number, and returns the record without checking that the signed-in user is allowed to see it. A user changes one number in a request and reads someone else's data, and a short script can repeat that for every record in the table. | HighAuthorization flaws such as IDOR are among the most common serious findings in web applications. | An ownership check on the server for every object it serves; the report lists each endpoint that is missing one. |
| Modern SQL injection vectors | Parameterized queries fixed the easy cases, and many teams now treat SQL injection as solved. It still turns up in places the usual protections do not reach: JSON path expressions, raw query fragments passed through an ORM, second-order queries where data saved earlier is later used to build a query, and dynamic ORDER BY clauses built from a sort parameter. | VariesDepending on the database account, the impact runs from reading data you never meant to expose to changing it. | The request that shows the issue and the safe pattern to replace it with. |
| DOM-based XSS in JavaScript bundles | Modern front-end frameworks neutralize most stored and reflected cross-site scripting. DOM-based XSS, where your own browser-side code writes untrusted data into the page, is now the dominant form, and scanners rarely catch it because it lives in the JavaScript bundle you ship rather than in the server's responses. | VariesWhen it works, an attacker's script runs in a signed-in user's browser with that user's access, which matters most when the user is an administrator. | Reproduction steps and a code-level fix, as for every finding in the report. |
| Chained findings: medium to critical | A detail leaked in one response, an endpoint that accepts that detail without checking who is asking, and a sensitive change that does not ask the user to sign in again are each a moderate concern; together they can hand one customer control of another customer's account. | Medium → CriticalThree findings that each look medium-severity in isolation can chain into full tenant takeover. | Each chain walked end to end and rated by what the chain achieves, because a list of separate medium ratings hides that kind of risk. |
05 / What you get
The report your team keeps using after we leave
The report is the part of the engagement your team keeps using after we leave, so it is written by hand, not assembled from tool output. The same report template can be shared during procurement on request, before you commit.
Show details for The report your team keeps using after we leave
- An executive summary built for non-technical readers: what was tested, what was found and what it means for the business, in language a founder, a product head or an auditor can follow.
- Engineer-grade write-ups with reproductions and exact payloads. Each finding has the steps to reproduce it, the payload used, its impact and a code-level fix, so a developer can confirm the issue and patch it from the report alone.
- Severity scored against CVSS 3.1 and your environment. A missing ownership check on a newsletter form and the same flaw on a payments endpoint do not deserve the same rating; the score reflects your architecture and your data.
- Methodology mapped to OWASP and ASVS, with the per-category coverage matrix that shows what was tested in each category and what was found.
- A remediation roadmap, so your team knows which fixes to schedule first.
Our sample VAPT report shows the structure.
Chain C-01 · Findings F-01, F-02, F-03
Account takeover across tenants through three medium findings
- Chain severity
- Critical
- Parts
- 3 × Medium
- Impact
- Tenant B account taken over
- Tested as
- Customer, tenant A
Chain
- F-01: a profile response leaks tenant B's user ID.
- F-02: the email-update endpoint accepts that ID without an ownership check.
- F-03: the email change is not confirmed by signing in again, so a password reset completes the takeover.
Fix
Remove the ID from the response, add a server-side ownership check to the update endpoint, and require signing in again for email and password changes.
Example layout, not client dataCVSS 3.1 · ASVS V4
06 / Price
What sets the price
A web application with logins and roles starts from INR 27,000 + 18% GST. That is a starting price, not a flat fee: larger applications, with more roles, functions and integrations, cost more, and the figure for your application is set after the scoping conversation, once those are known.
Web application with logins and roles
Starts fromINR 27,000 + 18% GST
Beyond the starter scope, every other test starts from INR 27,000 + 18% GST, and the final price depends on the number of roles, endpoints, hosts and environments in scope.
Request a scoping callStarter scope
Starts fromINR 9,000 + 18% GST
The starter scope is priced from INR 9,000 + 18% GST for small scopes such as 3 to 5 external IP addresses or a simple WordPress website, including a vulnerability scan, manual checks, a written report and one free retest.
Read the VAPT cost guideFive things set the testing time a web application needs, and with it the cost:
Roles
Customer, staff, manager and admin are four separate sets of permissions, and every pair of them is a possible privilege escalation to test.
Pages and functions
A brochure site with a contact form is a short list. A portal with orders, approvals, exports, reports and settings is a long one.
API endpoints
The more endpoints the application exposes, the more there is to test.
Integrations
Payment gateways, SSO providers, webhooks and file storage each add a trust boundary to check.
Environments
Testing more than one environment, or more than one tenant configuration, adds time.
Our VAPT cost guide for India explains each factor in more depth.
07 / Turnaround and retest
Turnaround, and what we need to start
Most web application tests take 5 to 10 working days. Where yours lands depends on the same factors that set the price: how many roles there are, how long the function list is and how much sits behind the integrations.
Show details for Turnaround, and what we need to start
- Working days for most web application tests
- 5 to 10
- The longer end, for multiple tenants, complex role hierarchies or deep integrations
- 2 weeks
Testing days are only part of the schedule. Before testing starts, we need three things from you.
What we need from you
- The application URLs.
- Test credentials for each role, so the time goes on what each kind of user can and cannot do.
- A short scope memo. The rules of engagement are then agreed in writing during scoping.
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
08 / Industries and location
Industries, and where we test from
The web applications we test come from pharma, fintech, SaaS, healthcare, VFX and media companies. The method stays the same from one industry to the next; the threat model changes.
Show details for Industries, and where we test from
SaaS
Tenant isolation, SSO and SCIM integration, admin-console privilege paths and webhook abuse.
Healthcare
Access boundaries around electronic health records and the integrity of telemedicine sessions.
Pharma
Vendor-portal sprawl, ERP exposure to partners and the integrations that keep clinical and manufacturing data flowing.
Media and VFX
Content exposure through review portals, IDOR across project boundaries and access controls on asset shares.
BERRY9 has one office, in Hyderabad, and web application tests are run remotely from there. An application that is reachable over the internet is tested the same way whether your team is in Hyderabad, Bangalore, Chennai, elsewhere in South India or anywhere else in India. For an internal portal that only answers inside your network, access such as a VPN account is agreed during scoping, and on-site testing can be arranged by agreement.
09 / Compliance evidence
Compliance evidence
Many web application tests are commissioned because an audit, a customer contract or a regulation calls for one. What the test can do is cover the scope your framework and your auditor need, and leave you with a report that shows what was tested, what was found and how to fix it.
Show details for Compliance evidence
SOC 2
Auditors look for evidence that the controls protecting your systems are tested. For the applications your customers use, a web application test report with its coverage matrix is one such piece of evidence.
ISO 27001
The standard expects technical vulnerabilities to be identified and managed. Testing your applications and tracking the findings to closure feeds that process. BERRY9 itself holds ISO/IEC 27001:2022 certificate 26MEQVU27; that certificate is ours and does not certify your organization.
PCI DSS
If your application stores, processes or transmits card data, or can affect the security of the systems that do, PCI DSS sets its own penetration testing requirements. The scope of the test is agreed with those requirements, and your assessor's expectations, in mind.
DPDP Act
India's Digital Personal Data Protection Act expects organizations to protect the personal data they handle with reasonable security safeguards. A web application test checks whether the systems holding that data expose it, and the report records that the check was made.
A penetration test report supports audit evidence; it does not replace the audit. BERRY9 does not certify or audit your organization against any framework, and no test can promise how an audit turns out.
10 / Inquiry
Send us your scope and timeline
Tell us about the application: what it does, roughly how many roles and integrations it has, and when the test needs to be finished. We will propose a scope and timeline.
If you would rather talk it through, call +91 86868 92922 or write to contact@berry9.com.
11 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
How long does a web application penetration test take?
A typical web application test runs 5 to 10 working days. Larger applications may extend to two weeks. See the section on Turnaround, and what we need to start above.
What does the deliverable look like?
An engineer-grade report containing an executive summary, the methodology mapped to OWASP and ASVS, detail for each finding (reproduction steps, payload, impact and a code-level fix) and a remediation roadmap. The same report template can be shared during procurement on request, and our sample VAPT report shows its structure.
Does the engagement cover the OWASP Top 10?
Yes. The OWASP Top 10 and ASVS Level 2/3 controls form the baseline coverage, and the report includes a per-category coverage matrix showing what we tested and what we found. Testing goes beyond the Top 10 into business-logic and chained findings, the high-severity bugs that scanners miss.
Are authentication and authorization tested?
Yes, in a dedicated phase. We test as multiple users across roles and tenants, and check session handling end to end, including SSO, JWT and password reset flows. See the section on Eight areas, tested within the agreed scope above.
Do you run black-box, grey-box or white-box tests?
Grey-box is the default, with test credentials for each role. Black-box testing suits an external-only scope, and white-box testing fits when a source code review is part of the same engagement. See the section on Eight areas, tested within the agreed scope above.
What do you need from us before testing starts?
The application URLs, test credentials for each role and a short scope memo. The rules of engagement are then agreed in writing during scoping. See the section on Turnaround, and what we need to start above.
Will testing disrupt our live application?
Testing is designed to be safe: impact is shown with validated proofs of concept, and we work to avoid disrupting your production environment. What we may demonstrate impact against, and what is a hard stop, is agreed in writing before testing begins.
How is a penetration test different from a vulnerability scan?
A scan runs automated checks and reports what matches known patterns. A penetration test adds an engineer who signs in as each role, tries your business rules, removes false positives and chains weaknesses together to show real impact. Scanners still run alongside the manual work for coverage; they do not replace it.
Will a penetration test make us compliant?
No single test makes an organization compliant. A web application test report is evidence you can use in SOC 2, ISO 27001, PCI DSS or DPDP Act work, but BERRY9 does not certify or audit your organization, and the outcome of an audit rests with your auditor.
Can you test our application if we are not in Hyderabad?
Yes. Web applications are tested remotely from our only office, in Hyderabad, so a company in Bangalore, Chennai or elsewhere in India is served the same way. On-site work can be arranged by agreement.