Cyber Security Testing
Web Application Security Testing
OWASP-aligned manual and automated testing of web applications, with validated proof-of-concept for every finding.
Every engagement includes manual validation, a two audience report and free re-testing.
Get a scoped quote+91 96682 00222What this actually is
Roughly four in five attacks land at the application layer, and it is easy to see why. Your web apps hold the customer data, they talk to the payment rails, and they change every sprint. A scanner run last quarter tells you very little about what shipped on Tuesday.
We test web applications the way somebody trying to get in would. Authentication and session handling, authorisation between roles and tenants, the business logic that no tool understands because it has no idea what your product is for. Everything we report has been reproduced by hand first.
You get a proof of concept for every finding, not a CVE number and a shrug. If we say an anonymous user can read another customer's records, we will show you the exact request that does it.
What we go after
- Authentication, session management and password reset flows
- Authorisation between roles, tenants and object references
- Injection across SQL, NoSQL, command, template and LDAP
- Business logic abuse, race conditions and workflow bypass
- File upload, deserialization and server-side request forgery
- Client-side issues including XSS, CSRF and DOM sinks
- Secrets, tokens and keys exposed in responses or bundles
- Rate limiting, enumeration and account takeover paths
How we run it
- 01
Scope and authorise
Targets, testing windows, escalation contacts and safety limits, all agreed in writing before anyone touches anything.
- 02
Map the surface
We enumerate what is actually exposed, which is usually more than the asset register says.
- 03
Test by hand
Tooling gives coverage, our engineers give proof. Every finding is reproduced before it is written down.
- 04
Report
An executive narrative your board can act on, and a technical annexe with the exact request, payload and fix.
- 05
Re-test and sign off
Once you have fixed it we verify each one at no extra cost, then close the engagement properly.
What you receive
- Executive summary written for a board, not for engineers
- Technical report with request, payload, evidence and fix for each finding
- Risk rating by real exploitability and blast radius, not raw CVSS
- Prioritised remediation plan sequenced by effort
- Free re-test report once fixes are in
- Safe to host or CERT-In certificate where applicable
Who needs this
Anyone shipping a customer-facing web application, and anyone whose regulator asks for annual application testing. If you take payments, hold personal data or serve citizens, this is the baseline.
How long it takes
One to three weeks for most applications, depending on the number of roles and the size of the authenticated surface.
Standards this satisfies
- OWASP Top 10
- OWASP ASVS
- CERT-In
- PCI DSS
- ISO 27001
Why it matters
A web application is usually the only part of an organisation deliberately exposed to everyone on the internet, guarded by a password, and changed every few weeks by a team under delivery pressure. That combination is why it remains the most common route into a breach.
The commercial driver is rarely fear, though. It is that an enterprise customer, an insurer or a regulator has asked for evidence, and scanner output will not satisfy them. A test that names what was verified, to what depth and against which standard is a document you can hand over. A tool report is not.
It matters most where the application carries something worth taking: payments, health records, identity data, or the ability to move money. There the question is not whether to test but how often, and whether testing keeps pace with how fast you ship.
Choose the depth you actually need
Most of the price difference between quotes comes down to this one choice, and it is rarely explained. Pick one to see what it covers, what it suits and what it costs you.
You give us working accounts at each privilege level and a short walkthrough. We then test what a real attacker reaches after the first stolen password, which is where the findings that matter almost always live. This is what we recommend for most engagements.
Choose this when
- Any application with authenticated functionality
- Multi-tenant products, where tenant isolation is the real risk
- Getting the most findings for the money
Effort and cost
Moderate effort and by far the best coverage per rupee. Most of the serious findings we report come out of authenticated testing rather than unauthenticated.
Tested against OWASP ASVS, not a checklist we invented
We test to the OWASP Application Security Verification Standard, which sets verification levels across authentication, session management, access control, input validation, cryptography, error handling and business logic. Working to a published standard means you can tell an auditor or a customer exactly what was verified and to what depth. It also makes this year's test comparable with last year's, which a bespoke in-house checklist never is.
Scope it yourself, before you call anyone
Answer a few questions and you get an indicative number, the working behind it and what your answers tell us. It runs in your browser, so nothing you type reaches us.
What needs testing?
Pick everything in scope. Effort is driven by unique functionality, not by how many IP addresses you own.
What we look for, and keep finding
These are the classes of problem this work exists to surface. Not every engagement finds all of them, but these are the ones that turn up often enough to be worth naming.
Broken access control
The most common serious finding we report, and the one scanners miss most reliably. An identifier that is not checked against the caller, an admin function reachable by guessing its path, a role that can be changed in the request. The user is logged in. They are simply reading or doing something that is not theirs.
Injection and unsafe query construction
SQL, NoSQL, OS command and template injection. Modern frameworks prevent most of it, which is exactly why the remaining cases hide in the hand written query somebody added under deadline, or in the reporting module nobody has looked at since it shipped.
Authentication and session weaknesses
Tokens that do not expire, password reset flows that can be redirected, multi-factor that can be skipped by replaying an earlier step, and sessions that survive a password change. We test the whole lifecycle rather than just the login form.
Business logic abuse
Nothing is technically broken. The application simply allows a sequence it should not: a discount applied twice, a payment confirmed before it clears, a limit avoided by splitting a request. This requires understanding what the application is for, which is why automation cannot find it.
Sensitive data exposure
Data returned by an API that the interface never displays, secrets in client side code, verbose errors that reveal structure, and personal data in logs. The response body is where we find most of it.
Security misconfiguration
Default credentials, directory listing, debug endpoints reachable in production, permissive CORS and missing security headers. Individually minor, and routinely the first step in a chain that ends somewhere serious.
Who runs your engagement
A senior tester, named before you sign
Testing is led by an engineer holding OSCP, CREST or equivalent, and you are told who it is before the engagement starts. They write the report themselves rather than handing notes to someone else, and they are on the call when findings are walked through. If the person changes, we tell you why.
Questions we get asked
Will testing take our site down?
No. We agree a testing window and safety limits with you first, we throttle anything that could affect availability, and there is a named contact on our side you can call to stop the test immediately. In over a decade we have not caused a customer outage.
Do you test in production or staging?
Staging is safer, production is more honest. Most clients do staging first and a lighter production pass afterwards. If staging is not a faithful copy, we will tell you, because testing the wrong build helps nobody.
What happens to the findings after you hand over the report?
They go into AppSec 360 with an owner and a due date, our engineers stay available to your developers while they fix, and we re-test every remediated item at no extra cost.
Can you issue a certificate we can show a client or regulator?
Yes. Once the re-test is clean we issue a certificate, and where CERT-In empanelment is required we issue the CERT-In security audit certificate or a Safe to Host certificate.
Often scoped alongside
- Mobile Apps Security TestingAndroid and iOS binary, runtime and API-layer assessment against OWASP MASVS.Read more
- Network Penetration TestingInternal and external network exploitation, lateral movement and privilege escalation testing.Read more
- API Security TestingAuthentication, authorisation, rate-limiting and business-logic testing across REST, GraphQL and gRPC.Read more
- Cloud Penetration TestingAWS, Azure and GCP configuration review, IAM privilege analysis and cloud-native exploitation.Read more
Ready to scope your web application security testing?
Thirty minutes with a senior engineer, and you leave with a written scope and indicative effort.