Web Application Testing

Why it matters

What this protects you from

• Account takeover

  Authentication and session flaws let an attacker who holds one password reach a full account, and often every account behind it.

• Customer data exposure

  Broken authorization is the most common way records leave an application. It rarely announces itself in logs.

• Business logic abuse

  Logic flaws pass every scanner because each individual request is valid. Only a human testing the workflow finds them.

• Regulatory exposure

  Demonstrable due diligence matters when a regulator or an enterprise customer asks how the application was assessed.

Coverage

What we test

• Authentication and session management

  Token scope and lifetime, MFA enrolment and replacement, logout and revocation, and password reset flows.

• Authorization and access control

  Horizontal and vertical privilege checks, tested at the API rather than only in the interface.

• Input handling and injection

  SQL, NoSQL, command, template and cross-site scripting across every parameter reachable in scope.

• Business logic

  Workflow sequencing, value tampering, quantity and pricing manipulation, and race conditions on state changes.

• API and backend trust

  Whether server-side controls still hold when the client is bypassed entirely.

• Configuration and security controls

  Headers, cookie flags, CORS, TLS configuration, and version or environment disclosure.

Approach

Three ways to run it

• Black box

  No credentials and no documentation. Mirrors an internet-based attacker with no prior access.

• Grey box

  Standard user accounts across each role. The most common choice, and usually the best value for the time spent.

• White box

  Credentials plus source code. Finds the most, because trust boundaries can be traced rather than guessed.

Process

How the engagement runs

1. 01

   Scoping and threat alignment

   We agree targets, roles, environments and exclusions in writing, then map the attack surface that actually matters to your business.

2. 02

   Manual recon and enumeration

   Full enumeration of routes, parameters, roles and API endpoints. Automated scanning is a starting point here, never the deliverable.

3. 03

   Targeted exploitation

   Confirmed exploitation of what we find, with evidence captured as we go. We do not report theoretical findings.

4. 04

   Impact analysis

   Each finding is scored with CVSS and classified with CWE, then adjusted for what it means in your environment specifically.

5. 05

   Reporting and remediation

   Written findings with reproduction steps, evidence and remediation guidance specific enough to hand to a developer.

6. 06

   Retest

   Once you have remediated, we retest the affected workflows and issue a retest summary confirming what is closed.

Standards

What we test against

OWASP ASVS

Verification requirements drive coverage, so testing is measured against a published standard rather than one tester's habits.

OWASP Web Security Testing Guide

Individual test cases are drawn from the WSTG, so coverage is reproducible between engagements and between testers.

NIST SP 800-115

Overall assessment structure follows the NIST technical guide, which is what most procurement teams expect to see referenced.

OSSTMM

Methodology discipline and scope control, so results are repeatable and testing stays inside its agreed boundaries.