Web application penetration testing

Scanners find the vulnerabilities that are easy to describe. We find the ones that are easy to exploit — broken authorisation between tenants, logic you can walk around, and the chains that turn three mediums into one critical.

Scope

What we actually test

Every item below is exercised by hand against your running application, with valid credentials for each role.

Authentication & session

Login, MFA enrolment and bypass, password reset flows, session fixation and invalidation, remember-me tokens, OAuth and SAML redirect handling, JWT verification paths.

  • OAuth / SAML
  • JWT
  • MFA bypass

Authorisation & multi-tenancy

Object-level access control across every role and every tenant. We build an authorisation matrix and then try to violate each cell of it — the single most common source of critical findings.

  • IDOR
  • BOLA
  • Tenant isolation

Business logic

Workflows abused out of order, negative quantities, race conditions on balance and quota operations, price and discount manipulation, approval steps skipped entirely.

  • Race conditions
  • Workflow abuse

Injection & data handling

SQL and NoSQL injection, template injection, command injection, deserialisation, XXE, and the file upload paths that lead to storage takeover or code execution.

  • SQLi
  • SSTI
  • Deserialisation

Server-side request forgery

SSRF reachability into internal services and cloud metadata endpoints, including DNS-rebinding and redirect-based filter bypasses.

  • SSRF → IMDS
  • Filter bypass

Client-side

Stored, reflected and DOM XSS, CSRF on state-changing operations, postMessage handling, clickjacking, CSP effectiveness and prototype pollution.

  • XSS
  • CSRF
  • CSP review

How it runs

How the engagement runs

  1. 01

    Scoping and rules of engagement

    NDA first, then a call to map your architecture, roles and what would genuinely hurt the business. You get a written scope, a testing window and a fixed price before anything starts.

  2. 02

    Attack surface mapping

    Every host, endpoint, parameter, role and third-party integration in scope is enumerated and catalogued — including the staging host nobody remembered owning.

  3. 03

    Threat modelling

    We define what an attacker wants from you — customer data, funds movement, tenant isolation, admin control — and write test cases backwards from those objectives.

  4. 04

    Manual exploitation

    Findings are proven rather than theorised, then chained to establish maximum realistic impact. Criticals reach you the same day, before the report exists.

  5. 05

    Reporting and debrief

    An executive summary for leadership and a technical report for engineers, followed by a live walkthrough where your team can question or challenge any severity rating.

  6. 06

    Retest and attestation

    Once you ship fixes, every finding is retested free within 90 days and the report is reissued with each issue marked verified-fixed, alongside a signed attestation letter.

Every engagement ships with

  • Executive summary written for leadership
  • Technical report with reproducible proof-of-concept for every finding
  • CVSS v3.1 vectors and a plain-English business-impact narrative
  • Prioritised, concrete remediation guidance
  • Same-day alerting on anything critical
  • Live debrief with your engineering team
  • Free retest of every finding within 90 days
  • Signed attestation letter for auditors and customers

FAQ

Questions about this service

How long does a web application test take?

Most applications need 5 to 15 working days of active testing plus 2 to 3 days for reporting. Scope drives the number, and you get both the timeline and the fixed price in writing before we begin.

Do you need credentials?

Yes — one account per role, ideally two per role so we can test tenant isolation properly. Unauthenticated-only testing misses the majority of high-impact findings, because access control bugs are only visible once you are inside.

Will testing break our production environment?

Rules of engagement are agreed in writing first: testing windows, request rate limits, forbidden actions, emergency contacts and a kill switch. Destructive and denial-of-service testing is never performed without explicit written approval.

Can you test a staging environment instead?

Yes, and it is often the better choice — provided staging genuinely mirrors production in code, configuration and data shape. Where it differs, we note the difference in the report so you know what was not covered.

What if you find nothing?

That result is reported honestly, along with exactly what was tested and how, so the report still functions as evidence for your auditors and customers. We do not pad reports with informational noise to justify an invoice.

Next step

Find out what an attacker would find.

Tell us what you have built. You get a reply within one business day, an NDA, and a free 30-minute scoping call with the person who will do the testing.