Web application penetration testing in Bangalore
Bengaluru's product companies are usually asked for a penetration test by a customer long before an auditor asks. BERRY9 tests your web application remotely from Hyderabad, our only office, with the accounts and tenant boundaries your enterprise buyers care about, and reports in the form a procurement team can read.
- Typical duration
- 5 to 10 working days
- Testing
- Manual, by engineers
- Report
- Executive + engineering
- Delivery
- Remote from Hyderabad, on-site by arrangement
Last reviewed
01 / Local need
Why Bangalore product teams ask for a web test
For most, the request starts in a customer's procurement review and not in the security team.
A Bengaluru SaaS company that wins its first large customer meets a security questionnaire the same week. A supplier to a global capability center is told that its application will be tested before it connects to the customer's systems. A funded startup preparing for SOC 2 learns that the auditor will want evidence of how vulnerabilities are found. The common thread is a deadline set by someone else and a question that only a test can answer.
Our work for Bengaluru teams is built around the release calendar. Tell us which build you plan to publish and the date a customer wants the report, and the testing window is planned around both. The method is set out on the web application testing page, while VAPT services in Bangalore covers how buyers in the city usually compare firms.
02 / Scope
What a Bangalore product team gets tested first
Fast release cycles and many customers behind one application shape the scope.
The multi-tenant product
One application, many customers. We test whether any request, export or background job can cross from one tenant to another, with accounts in at least two tenants.
Features shipped last month
A fast release train changes the risk each sprint. We scope the newest features first, and the proposal says which releases the report covers, so a buyer can see what was tested.
Sign-up, trials and invitations
Self-serve sign-up lets strangers create accounts at scale. We test trial abuse, invitation flows that accept any address and the limits on creating accounts.
Billing and subscription pages
Plan changes, seat counts and invoices are logic that can be bent. We test whether a customer can change a plan, a price or a limit by editing a request.
Admin and support tooling
Support staff need to see inside a customer's account. We test how that access is gated, logged and limited, and whether a customer can reach the same functions.
Public pages and documentation
Marketing sites, help centers and status pages sit on the same domain as the product. We check they cannot be used to take over sessions or leak internal addresses.
03 / From our guide
From our guide: the OWASP Top 10:2025
Buyers and auditors increasingly name the OWASP Top 10 in their requests, and the 2025 edition changed what a current report should cover. This is the part of our guide Bengaluru teams ask about most.
The ten categories in the 2025 list
- A01 Broken Access Control. Still first on the list.
- A02 Security Misconfiguration.
- A03 Software Supply Chain Failures. New in this form.
- A04 Cryptographic Failures.
- A05 Injection. Down from third place.
- A06 Insecure Design.
- A07 Authentication Failures. Renamed from "Identification and Authentication Failures".
- A08 Software or Data Integrity Failures.
- A09 Security Logging and Alerting Failures. Renamed from "Logging and Monitoring".
- A10 Mishandling of Exceptional Conditions. New.
What changed, and why it matters
Server-side request forgery is now part of access control
SSRF had its own slot in 2021. In 2025 it is rolled into A01, which fits how it behaves in practice: the server is tricked into making a request the user was never allowed to make, often to internal services or cloud metadata. For a tester it means SSRF checks belong in the same pass as authorization checks, and for a developer it means egress rules and allow-lists are an access control job.
Supply chain failures widen "outdated components"
A03 grows the old "Vulnerable and Outdated Components" idea to cover dependencies, build systems and distribution infrastructure. OWASP notes that this category has the fewest occurrences in the contributed data, yet the highest average exploit and impact scores, and says it expects testing to catch up. In plain terms: a compromised package or build pipeline is rare in test data because it is hard to test, not because it is rare in the real world.
Mishandling of exceptional conditions is new
A10 covers improper error handling, logic errors and systems that fail open when something unexpected happens. A payment check that is skipped when the fraud service times out is an example. These bugs hide in code that only runs when things go wrong, so scanners rarely find them and manual testing has to provoke them.
Injection falls, but does not go away
Injection drops from third to fifth. Frameworks and scanners now catch much of it, which is why the ranking fell, not because attackers lost interest. Cross-site scripting sits in this category with SQL injection, one frequent and low impact, the other less frequent and high impact.
Alerting, not just logging
A09 now says "alerting" because logs nobody reads do not stop an incident. A good test asks whether a burst of failed logins or a run of access-denied errors would reach a person.
If your last report mapped findings to the 2021 list, ask your next tester to map to the 2025 one. The rest of the guide, including how to test each new category, is in the full OWASP Top 10:2025 article.
04 / What we find
Weak points that recur in Bengaluru product applications
The same short list of flaws turns up across very different products.
Show details for Weak points that recur in Bengaluru product applications
- Tenant checks missing on the side doors. The main screen checks who owns a record; the CSV export, the nightly report or the search index quietly skips that check.
- Invitation and share links that outlive their purpose. A link meant for one colleague that works for anyone, and never expires.
- Limits that only the interface enforces. A plan that allows five seats in the settings page but accepts a sixth through the request behind it.
- Helpful errors. Messages that name internal hosts, query fragments or library versions.
- Reset tokens that stay valid. Password reset and email change links that work after use, or after a second request.
- Hidden routes in the front-end bundle. Admin paths that are unlinked but listed in the JavaScript the browser downloads, and answered without a role check.
Severity is judged against your product: an unlisted export is minor on a marketing site and serious where one tenant's contracts could be read by another. The report ranks fixes by how many customers each one protects.
05 / Rules and customers
SOC 2, ISO 27001 and customer questionnaires in Bangalore
The test usually serves a framework or a named customer, so it helps to know what each one looks for.
Show details for SOC 2, ISO 27001 and customer questionnaires in Bangalore
SOC 2 does not require a penetration test. Its criteria ask for controls that find and manage vulnerabilities, penetration testing is one common way to show that, and your auditor decides what evidence is enough. For Bengaluru startups the SOC 2 testing page shows how a report becomes evidence. ISO 27001 programs ask for a regular, risk-based testing routine and for proof that findings were acted on.
Customer questionnaires are the bigger driver, and they ask three things: the date of your last independent test, its coverage, and what became of the serious findings. Our article on a startup's first penetration test explains how to time one around a deal, and how often to test gives a schedule tied to your releases.
06 / How it runs
How a web test fits a Bangalore release calendar
The schedule is shaped by your releases, not by travel.
Show details for How a web test fits a Bangalore release calendar
Before day 1
Scoping over a call
We agree the application, the environments, the roles and the release the report will cover, and fix the testing window around your sprint calendar.
Day 1
Access and addresses
You share staging access and one account per role in two tenants. We send the fixed addresses our traffic comes from so your team can recognize it.
Days 2 to 7
Testing between releases
We test by hand and flag anything urgent at once. If a release lands mid-test, we note which findings were seen before and after it.
OutputFindings with proof, tagged to the build tested
07 / Questions to ask
Five questions to put to any web tester you shortlist
Five questions separate a test a buyer will accept from one they will not.
Show details for Five questions to put to any web tester you shortlist
- How many accounts, in how many tenants, will you test with, and who chooses them?
- Which build will the report name, and how do you record it?
- How do you treat exports, background jobs and search, not only the screens?
- Is the summary written so that a customer can read it without you in the room?
- What happens to a finding after our fix, and who confirms it is closed?
08 / Delivery
How we deliver a web test to Bangalore teams
Where the work happens
Testing is run from our office in Yellareddyguda, Hyderabad, which is our only office. Outside Hyderabad nothing about these tests needs us in your building; if a customer or a site rule asks for someone present, we come by arrangement and write the travel cost into the proposal.
What you receive
One report is written for management, customers and auditors, and a second, more technical one for the engineers who make the fixes. A walkthrough call covers both, and after your fixes we retest and mark each finding closed or open. Every inquiry gets a reply: we respond within 24 hours.
How to prepare
Test accounts, a staging address, our testing addresses allowed through your firewall and a named contact are what we ask for. The preparation article explains each item, and the one-page checklist (PDF) is a printable version.
09 / Price
What a web test costs a Bangalore team
If the scope is a handful of public pages, a small scope comes 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. A SaaS product with users, roles and data is a bigger job, in the standard band: tests begin from INR 27,000 + 18% GST, and tenants, roles, endpoints and environments move the final figure. The cost guide for web application testing shows the factors.
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
10 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
Do you have an office or testers in Bangalore?
No. Everything we do for Bengaluru teams is delivered from Hyderabad, and nothing in a web application test needs a visit. See the section on How we deliver a web test to Bangalore teams above.
How do you handle a product that ships every week?
We agree the build the report will cover, test staging on that build and note any release that lands mid-test, so each finding is tied to a version a buyer can identify. See the section on What a Bangalore product team gets tested first above.
Will the report satisfy an enterprise customer's questionnaire?
That is the buyer's call, so we cannot promise it. The executive report states scope, method, findings and retest status in a form designed to be forwarded. If you share the questionnaire, we shape the scope around it. See the section on SOC 2, ISO 27001 and customer questionnaires in Bangalore above.
Is a penetration test a SOC 2 requirement for us?
SOC 2 does not require a penetration test. Its criteria ask for controls that find and manage vulnerabilities, penetration testing is one common way to show that, and your auditor decides what evidence is enough. See the section on SOC 2, ISO 27001 and customer questionnaires in Bangalore above.
Can you test while engineers keep deploying?
Yes, if we test staging and you tell us about releases in the window. We record the build for every finding, and we retest on the build that contains your fixes. See the section on How a web test fits a Bangalore release calendar above.
Is the price different for Bangalore?
No, the rates are national: a small scope comes 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, and larger products begin from INR 27,000 + 18% GST. See the section on What a web test costs a Bangalore team above.
Plan your next security test
Tell us what needs testing and when you need it done, and we will propose a scope and timeline. We respond within 24 hours. If you would rather talk first, call or write to us.
- +91 86868 92922
- contact@berry9.com
- H.No: 8-3-945/A/12 & 13, Sri Venkata Sai Nest Apartments, Nagarjuna Nagar Colony, Yellareddyguda, Hyderabad 500073, Telangana