Web application penetration testing
A web application penetration test is a manual, authorised attack on your application by testers who try to do what a real attacker would: log in as someone else, read another customer's data, skip a payment step or take over an admin account. ITovio tests by hand, proves every finding and retests after you fix.
Enterprise only. Cyber security is the one service ITovio offers at enterprise level: established companies and enterprises with production systems worth attacking properly. We do not sell low-budget scans or small-business security packages.
- SaaS platforms and customer portals holding other companies' data.
- Fintech, payments, marketplaces and booking platforms where business logic is money.
- Enterprises shipping a major release, a new tenant model or a rebuilt login.
- Teams whose enterprise customers now demand an independent test before signing.
Definitive results, not maybes
Proven, not suspected
Every finding in the report is exploited by hand and shipped with a working proof of concept, reproduction steps and evidence. No unverified scanner output, no "potential" issues padding the page count.
Ranked by business impact
Severity is scored with CVSS and then argued in plain language: what an attacker reaches, which data, which customers, what it would cost you.
Closed means closed
After you fix, we attack the same issue again. The retest report states, per finding, whether it is closed, partly closed or still open.
A clean result is still a result
If a target holds, the report says exactly what was attacked, how and for how long, so "nothing exploitable found" is evidence you can hand to a customer, auditor or board.
What we attack
The work follows the OWASP Web Security Testing Guide, then goes past it where your application is unusual.
| Area | What we try to break |
|---|---|
| Authentication | Login, MFA and passkey flows, password reset, magic links, SSO and OAuth/OpenID Connect redirects, session fixation, token reuse after logout |
| Access control | Reading or changing another user's or tenant's records (IDOR), privilege escalation from user to admin, hidden admin functions, role checks enforced only in the browser |
| Business logic | Skipping steps, negative quantities, coupon and refund abuse, approval workflows, race conditions on balances and limits |
| Injection | SQL and NoSQL injection, server-side template injection, command injection, LDAP and XPath where present |
| Server-side flaws | Server-side request forgery into internal services and cloud metadata, insecure deserialisation, XML external entities, path traversal |
| File handling | Upload bypasses, stored XSS through files, processing of documents and images, exposure of other users' files |
| Client side | Cross-site scripting, DOM-based flaws, CSRF, CORS misconfiguration, postMessage abuse, clickjacking on sensitive actions |
| Infrastructure behind the app | Web cache poisoning and deception, HTTP request smuggling, exposed debug endpoints, verbose errors and secrets in front-end bundles |
Why manual testing finds what scanners cannot
A scanner knows what a vulnerability looks like. It does not know that invoice 1043 belongs to a different customer, that a discount should not apply twice, or that a support agent should never see a payroll export. Those are the findings that end up in breach reports, and they are found by people reading the application the way an attacker does.
We use automated tooling for coverage and speed, then spend the engagement on what it cannot do: authorisation across every role, business logic, and chaining small issues into one serious attack path.
What we need from you
- Written authorisation from the owner of the application and its hosting.
- Two test accounts per role, in at least two tenants if the application is multi-tenant.
- A test window, a technical contact and an emergency stop contact.
- For grey or white box testing: API documentation, architecture notes or source code access.
Asked before most engagements
How long does a web application penetration test take?
Black box, grey box or white box?
Can you test in production?
Do you test against the OWASP Top 10?
Who is this for?
Reviewed by the ITovio security team on 3 November 2026.
Related
API penetration testing for REST and GraphQL
Read itServiceCloud penetration testing for AWS, Azure and Google Cloud
Read itGuideWhat is in our penetration test report
Read itGuidePenetration test vs vulnerability scan: the real difference
Read itAll specialist testing: API testing, Cloud testing, Network and Active Directory, Mobile app testing, AI and LLM testing, Red team and attack simulation.
Find out what an attacker would find first.
A 30-minute scoping call, then a written scope with targets, depth, windows and deliverables before you commit. Enterprise engagements only.
