Broken access control
Horizontal and vertical privilege escalation, insecure direct object references, forced browsing and multi-tenant isolation failures. Consistently our highest-impact finding class.
Application Security
Web application testing that goes past the scanner.
Automated scanners find missing headers and known CVEs. They do not find the checkout flow that lets a customer set their own price, or the admin endpoint that trusts a header. That is the part that needs a person.
OWASPTop 10 & ASVS
Multi-roleAuthenticated testing
ManualBusiness-logic review
FreeRetest cycle
Why authenticated, multi-role testing is the whole game
Most web application tests are run unauthenticated, because unauthenticated testing is cheap and easy to schedule. It also misses the majority of what matters. The serious flaws in a modern application are almost always behind the login: one tenant reading another tenant’s records, a support role that can escalate itself to administrator, an object identifier that is not checked against the session that requested it.
We ask for credentials for every role your application has — customer, staff, administrator, and any partner or API role in between. Then we test each boundary in both directions. Can a customer reach staff functionality? Can one customer reach another customer’s data by changing a number in a URL? Can a low-privilege staff account perform an action the interface never offers it?
Alongside that we run full automated coverage, because there is no reason a human should be hunting for an unpatched library version. Our engine carries version-aware rules across 50 technology packs and 27 languages, so framework, server and dependency issues are identified precisely — the exact affected build, not a guess from a banner. That frees the manual effort for the logic, which is where the money is.
Coverage
What we test
Coverage follows the OWASP Web Security Testing Guide, with the depth set by the ASVS level you need to reach.
Authentication and session management
Credential handling, password reset flows, multi-factor implementation, session fixation, token lifetime and logout behaviour.
Injection
SQL, NoSQL, command, LDAP and template injection, including second-order cases where the payload lands somewhere other than where it was entered.
Business logic
Workflow bypasses, race conditions, price and quantity manipulation, replay of one-time operations, and any sequence the developers did not expect anyone to attempt.
Cross-site scripting and request forgery
Reflected, stored and DOM-based XSS, plus CSRF on state-changing operations and the CORS policy that quietly permits it.
Server-side request forgery and file handling
SSRF into internal services and cloud metadata endpoints, unrestricted upload, path traversal and unsafe deserialisation.
Cryptography and data exposure
Transport configuration, at-rest handling of sensitive fields, key and secret management, and personal data appearing where it should not.
Configuration and dependencies
Framework and server hardening, security headers, error handling, exposed administrative interfaces, and third-party components carrying known vulnerabilities.
Approach
How a web application test runs
Five to eight working days of testing for a typical application, then two to three for reporting.
-
01 · Understand the application
A short walkthrough with someone who knows it. What it does, who uses it, which data matters most, what a worst-case abuse would look like. This hour saves days.
-
02 · Map the surface
Every route, parameter, role and integration point, including the endpoints the interface never calls but the server still answers.
-
03 · Automated coverage
Full sweep for known vulnerabilities, misconfiguration, exposed files, dependency risk and hardening gaps — matched against current vulnerability intelligence.
-
04 · Manual testing
Access-control matrix testing across roles, injection and logic testing, and exploitation of anything the automated pass flagged as interesting.
-
05 · Prove impact
Confirmed findings only. Each one carries the evidence, the reproduction steps and a plain statement of what an attacker gets out of it.
-
06 · Report and retest
Ranked report, developer walkthrough, then a free retest once fixes ship.
Run against recognised standards
- OWASP Top 10The baseline risk categories
- OWASP ASVSVerification level agreed during scoping
- OWASP WSTGTest case coverage
- CWEWeakness classification in every finding
- ISO 27001 Annex AControl mapping for audit evidence
Deliverables
What you actually receive.
The report is the product. If it cannot be acted on by a developer and understood by a director, we have not finished.
Ranked findings with proof
Screenshots, requests and responses, and steps a developer can follow to reproduce the issue in five minutes.
Fixes written for your stack
Remediation guidance specific to the framework you are actually using, not generic advice copied from a standard.
ASVS coverage statement
Which verification requirements were tested and which passed, if you are working towards a stated ASVS level.
Developer walkthrough
A call with your engineering team to work through the findings and answer implementation questions.
Free retest and closure summary
Verification that fixes hold, and a shareable letter confirming the outcome.
Is this for you?
Talk to us if any of these are true.
If none of them are, say so on the call and we will tell you honestly whether this is the right piece of work — or point you at the one that is.
Book a scoping call- The application handles payments, personal data or health records.
- You have added a customer-facing portal or a self-service area to an existing product.
- You are multi-tenant, and tenant isolation has never been independently tested.
- A customer or auditor has asked for an application penetration test specifically, not a network scan.
- You have shipped fast for two years and nobody has looked at the authorisation model since.
How we work
Six steps, and no surprises.
The same engagement model applies to every piece of work we take on, so you always know what happens next.
01
Scope
A 30-minute call, then a written scope: what is in, what is out, what we need from you and what it costs. Nothing starts before you sign it.
02
Authorise
Rules of engagement, testing windows, escalation contacts and a signed authorisation. Out-of-hours windows where production cannot take the load.
03
Test
Automated coverage first, then manual testing where judgement is required. Critical findings are reported the day we confirm them, not at the end.
04
Report
One report a developer can act on and an executive can read, with evidence, reproduction steps, business impact and a fix for every finding.
05
Remediate
A walkthrough call with your engineers. We answer questions on the fix, not just the finding.
06
Retest
A free retest cycle to confirm the fixes hold, and a clean summary you can hand to a customer, auditor or board.
Questions
Web Application Testing — answered.
The questions clients actually ask during scoping. If yours is not here, ask it directly.
Do you need credentials to test our application?
Yes, and preferably two accounts per role. Unauthenticated testing covers only the small part of an application that is exposed before login, and the highest-impact flaws we find — one user reading another user’s data, a support account escalating to administrator — are only reachable with valid sessions. Two accounts per role let us test isolation between users at the same privilege level, which is where multi-tenant applications usually fail.
Will you test our production environment?
If you want us to, yes, within agreed windows and with intrusive testing excluded by default. Many clients prefer a production-identical staging environment for the deeper work and a controlled subset of checks against production. Configuration differences between the two are themselves a common source of findings, so we usually recommend at least some production coverage.
How is this different from a vulnerability scan?
A scan is one automated pass that reports known vulnerability signatures and misconfiguration. It cannot reason about your application. It will never notice that a discount code can be applied twice, that an order can be confirmed without payment clearing, or that changing a single identifier returns another customer’s invoice. Those are the findings that matter, and they require a person who understands what the application is for.
What is OWASP ASVS and do we need a level?
The Application Security Verification Standard defines three levels of rigour: Level 1 for low-assurance applications, Level 2 for most applications handling meaningful data, and Level 3 for the highest-value systems. You do not need to pick one, but naming a target level makes the test measurable — we can state which requirements passed rather than only listing what failed. Most commercial applications should be aiming at Level 2.
Can you test single-page applications and modern frameworks?
Yes. React, Angular, Vue and similar front-ends shift most of the interesting surface onto the API behind them, so an SPA test is largely an API test plus client-side analysis — DOM-based issues, secrets in bundled JavaScript, and logic wrongly enforced in the browser rather than on the server. Our definition library covers front-end and back-end frameworks across 27 languages and runtimes.
How often should we test?
Annually as a minimum, and after any significant change to authentication, authorisation, payment flows or the data model. Applications that ship weekly benefit more from continuous coverage between annual manual tests, which is what the platform is for.
Next step
Get a written scope and a fixed price.
A 30-minute call, then a scope document with what is in, what is out and what it costs. No obligation, and no charge for the conversation.