Web Application Security Testing

We run a controlled, adversarial assessment of your application: its code, its logic, its configuration, and the way it handles data under pressure. Automated scanning finds checklist vulnerabilities. We test the way attackers target you. We aim to find the issues that matter, show how someone could use them, and give your developers a clear path to fix them. We do not hand you a pass-fail certificate.

The person who scopes your test delivers it. We do not hand off to junior staff once you sign.

Who this is for / when to test

• Significant change: a new application, a major feature, an architecture shift, or a migration before go-live.
• Compliance and assurance: PCI-DSS, ISO 27001, SOC 2 and similar frameworks expect periodic application testing, and many require it annually.
• Customer and tender requirements: enterprise buyers increasingly ask for a recent independent test report before they sign.
• Post-incident: you confirm the root cause is fixed and no adjacent weaknesses remain.
• Annual assurance: your last test is more than twelve months old, or the application has changed materially since.

What we test

• Authentication and session management: brute-force and credential-stuffing resistance, session fixation, token predictability, and MFA bypasses including push abuse and verification race conditions.
• Authorisation and access control: object-level (IDOR/BOLA) and function-level (BFLA) checks, tenant isolation in multi-tenant systems, and horizontal and vertical privilege escalation.
• Input handling and injection: SQL, NoSQL, command, LDAP, XPath and template injection, plus SSRF, XXE and path traversal.
• Cross-site scripting and client-side security: stored, reflected and DOM-based XSS, CSP bypasses, prototype pollution, and unsafe postMessage and storage usage.
• Business logic and workflow abuse: step-skipping, replay, price and quantity tampering, coupon abuse, and race conditions in checkout and payment flows.
• APIs and modern architectures: REST, GraphQL, gRPC and WebSocket endpoints, including GraphQL introspection abuse, depth/complexity denial of service, and field-level authorisation.
• Cryptography and secrets: TLS configuration, cookie flags, token generation, and credentials leaked into source, config or logs.

Our methodology

We work to the OWASP Web Security Testing Guide (WSTG), validate coverage against the OWASP ASVS, and reference the OWASP Top 10 and OWASP API Security Top 10 so findings map to recognised standards.

1. Scoping: we agree boundaries, environments, credentials and any out-of-scope functionality with the consultant who will run the test.
2. Reconnaissance and enumeration: we map endpoints, parameters, technologies and dependencies to understand the real attack surface.
3. Mapping and threat modelling: we build a model of the application’s architecture, trust boundaries and state transitions.
4. Vulnerability analysis: we analyse the application by hand to identify weaknesses, and we use automated tooling only to catch low-hanging fruit.
5. Exploitation: we validate every issue through controlled exploitation. If we claim SQL injection, we will have extracted data. We do not report theoretical findings.
6. Reporting and debrief: we write findings up clearly and run a live debrief call to walk your team through them.
7. Retest: we retest every remediated finding to confirm the fix holds and introduces no regressions.

Testing approaches

• Black box: no prior knowledge or credentials, simulating an external attacker. It adds perimeter realism but runs slower and covers less ground.
• Grey box: limited credentials and context for each role. This is our default for web applications. It reflects the most common real-world threat, an authenticated user, and gives the broadest coverage for the time spent.
• White box: full access to documentation and sometimes source. Choose this when you need maximum depth on a high-risk application.

We recommend grey box for most engagements and will tell you where white box earns its place.

What you get

• An executive summary written for non-technical stakeholders.
• Technical findings with evidence and clear reproduction steps.
• Per-finding remediation written for the engineer who will implement the fix.
• A CVSS severity rating alongside a business-risk rating, so priority reflects your context and not just a score.
• Same-day notification of any critical finding. You hear about it the moment we confirm it, not at the end of the engagement.
• A debrief call to talk through findings and answer questions.
• A retest of remediated findings, included.

We write reports by hand: an executive summary your board can read, and dev-ready detail your engineers can act on.

FAQs

How long does a test take? Most web application tests run between three and ten working days depending on size, roles and API surface. We confirm duration at scoping.

Will it disrupt live systems? We routinely test production safely, agreeing rate limits, change-freeze windows and escalation contacts in advance. A staging environment that mirrors production is often preferable for destructive checks.

Can it be done remotely? Yes. Web application testing is delivered remotely from the UK.

How is this different from a vulnerability scan? A scan flags known patterns automatically and produces false positives. In a penetration test we think like an attacker, chain issues together, reason about your logic, and confirm real impact.