Services
Web Application Penetration Testing
Find the weaknesses an attacker would use against your web application — authentication gaps, broken access control, and logic flaws — and get clear guidance on fixing them.
What a web application penetration test is for
A web application penetration test is a controlled, authorised attempt to find and demonstrate security weaknesses in your application before someone else does. It looks at the application the way a determined attacker would: how users sign in, what they can reach once they do, how data moves through forms and APIs, and whether the application's rules can be bent to do something it shouldn't.
The goal is not a long list of theoretical issues. It is a set of validated findings — each one confirmed, explained, and prioritised — so your team can fix what matters first and show customers, partners, or auditors that the application has been independently tested.
What we test
Every engagement is scoped individually. Depending on your application and the agreed scope, testing typically covers the following areas.
Authentication
Sign-in, registration, password reset, multi-factor flows, and account recovery — looking for ways to bypass, brute-force, or take over accounts.
Authorization and access control
Whether users can reach data or actions that belong to other users, other tenants, or higher-privileged roles — including insecure direct object references and missing server-side checks.
Session handling
How sessions and tokens are issued, stored, expired, and invalidated, and whether they can be stolen, fixed, or reused.
Input handling
Injection flaws such as SQL and command injection, cross-site scripting, server-side request forgery, unsafe file uploads, and similar issues arising from untrusted input.
Business logic
Flaws in the application's own rules — skipping workflow steps, manipulating prices or quantities, abusing limits, or chaining features in ways the designers didn't intend.
Configuration and exposure
Security headers, error handling, information leakage, exposed administrative functions, and client-side code that reveals more than it should.
Not every area applies to every engagement. The areas tested are listed in the scope we agree with you before work starts.
Manual testing, not just a scan
Automated scanners are good at spotting known patterns — missing headers, outdated components, some classes of injection. They are poor at understanding what your application is supposed to do, so they routinely miss the issues that cause real incidents: one customer reading another customer's records, a user promoting themselves to administrator, or a checkout flow that can be manipulated.
We use automated tooling to support coverage, then spend most of the engagement on manual testing: mapping the application, understanding its roles and workflows, and deliberately trying to break its assumptions. Every reported finding is reproduced and confirmed before it reaches your report.
Authenticated and unauthenticated testing
Where agreed, we test with accounts at each relevant role so access-control boundaries can be checked from every side.
Staging or production
We recommend testing a production-like staging environment. If production must be tested, we agree safeguards and timing with you first.
What you receive
At the end of the engagement you receive a written report that includes:
- An executive summary of the overall security posture and the most important risks, written for non-specialists.
- Each finding with a risk rating, affected URLs or functions, evidence, and step-by-step reproduction instructions.
- Practical remediation guidance for each finding, with prioritisation to help you plan the fixes.
- A walkthrough of the findings with your team to answer questions.
- Retesting of fixed issues and an updated report, where retesting is part of the agreed engagement.
Before testing starts
- A written scope listing the application URLs, environments, user roles, and anything out of bounds.
- Written authorization from someone with the authority to approve testing of the application and its hosting.
- Test accounts for each in-scope role, provided through a secure channel we agree — never through the website form.
- A technical contact on your side for questions and for anything urgent found during testing.
Please don't send credentials, keys, or vulnerability details through the website form. We agree a secure channel once an engagement is confirmed.
Engagement process
From first conversation to verified fixes
A simple, predictable process. Actual timing and deliverables depend on the scope we agree.
Swipe to see all 6 steps
FAQ
Web App Pentesting: common questions
Can't find your answer? Ask us directly, or browse every question in the full FAQ.
A scan runs automated checks for known issues. A penetration test adds manual investigation of how your application actually works — access control, workflows, and logic — and confirms every finding. Many of the most serious web application flaws can only be found manually.
Testing is planned to avoid disruption. We agree environments, timing, and any techniques to avoid (for example, high-volume tests against production) during scoping, and we stop and contact you if anything unexpected happens.
The application's own API calls are naturally exercised during testing. If your API is also used directly — by mobile apps, partners, or customers — we recommend including dedicated API security testing in the scope.
It depends on the size and complexity of the application, the number of user roles, and the depth agreed. We estimate effort once we understand the application during the initial discussion.
Related services and resources
- API Security TestingDedicated testing for APIs used by mobile apps, partners, or customers.
- Secure Code ReviewFind the root cause of issues in source code, alongside or after a test.
- Our methodologyHow we scope, test, rate, and report findings.
- Glossary: SSRF, XSS, IDOR and morePlain-language definitions of common web vulnerabilities.
Planning a web application test?
Tell us about your application, API, or software security requirements. We can discuss the appropriate scope and next steps.
What happens next
- 01We review your enquiry and reply by email
- 02An initial discussion about your application and goals
- 03A written scope — nothing is tested until it's agreed