Skip to main content
B‑52
Request a $500 scan
Coverage class · Web

Web application penetration testing that works the flows

Most of what a web application gets wrong is not a payload that a signature catches. It is a role reaching data it should not, a step taken out of order, or a token trusted further than it should be. B-52 maps the application before it tests it, so the test cases come from what this application does.

Request a $500 scan Request a scoping call

Where this sits

Against what you already pay for

These are categories of work sold as web application security testing, and the question is which one answers which problem.

Vulnerability scannerTraditional engagementBug bountyB-52
What it works from A signature catalogue. An auditor’s reading of the application. Whatever a researcher chooses to look at. A test set generated from a mapping of this application.
Access-control defects Largely out of reach: the responses are well formed. Yes, within the hours bought. Often, and this is where researchers do well. Worked as a class, with a credential per role.
Business logic No. Yes, within the hours bought. Sometimes. Flows taken out of order and by the wrong role.
Coverage of the test set Complete, against its own catalogue. Sampled to fit the timebox. Whatever was attempted. The generated set is worked through in full.
What a finding costs you to confirm Triage. A share of them are not real. Usually nothing; it was proved. Triage, and a negotiation about severity. Nothing. It arrives with the exchange that proved it.
Cadence Continuous. When it is scheduled and staffed. Continuous, and outside your control. The interval you set, or the pipeline that built the release.
Whose signature it carries None. The firm that ran it. None. Security Brigade’s, in the two models with an empanelled auditor in them.

What it works from

Vulnerability scanner
A signature catalogue.
Traditional engagement
An auditor’s reading of the application.
Bug bounty
Whatever a researcher chooses to look at.
B-52
A test set generated from a mapping of this application.

Access-control defects

Vulnerability scanner
Largely out of reach: the responses are well formed.
Traditional engagement
Yes, within the hours bought.
Bug bounty
Often, and this is where researchers do well.
B-52
Worked as a class, with a credential per role.

Business logic

Vulnerability scanner
No.
Traditional engagement
Yes, within the hours bought.
Bug bounty
Sometimes.
B-52
Flows taken out of order and by the wrong role.

Coverage of the test set

Vulnerability scanner
Complete, against its own catalogue.
Traditional engagement
Sampled to fit the timebox.
Bug bounty
Whatever was attempted.
B-52
The generated set is worked through in full.

What a finding costs you to confirm

Vulnerability scanner
Triage. A share of them are not real.
Traditional engagement
Usually nothing; it was proved.
Bug bounty
Triage, and a negotiation about severity.
B-52
Nothing. It arrives with the exchange that proved it.

Cadence

Vulnerability scanner
Continuous.
Traditional engagement
When it is scheduled and staffed.
Bug bounty
Continuous, and outside your control.
B-52
The interval you set, or the pipeline that built the release.

Whose signature it carries

Vulnerability scanner
None.
Traditional engagement
The firm that ran it.
Bug bounty
None.
B-52
Security Brigade’s, in the two models with an empanelled auditor in them.

The honest part

A scanner is good at the part it is good at

Injection, known component versions and misconfiguration are exactly what a signature catalogue is for, and running one is not a mistake.

The class

What is inside a web application assessment

Everything the application serves over HTTP and everything the browser runs: the server-side routes, the authentication and session handling, the authorisation decisions behind every one of them, and the client-side code. Single-page applications are in scope as applications and not as pages, which means the API behind them is worked as part of the same assessment when it is inside the authorised scope. Where an application is large enough that its API is a separate product with its own consumers, it is scoped as its own class instead.

The boundary

What sits outside it, and which class it belongs to

Adjacent

The API as its own target

An API with consumers other than this front end is assessed as its own class, against its own specification, with its own authorisation matrix.

Adjacent

The infrastructure underneath

The host, its exposed services and the network it sits on are an external or internal network assessment.

Adjacent

The source, read directly

B-52 reads client-side code as part of every web assessment. Reading the server-side source is a different piece of work with a different denominator.

Out of scope

Physical, hardware and wireless

Out of scope for the platform entirely, in every class. It is the only exclusion, and it is stated the same way everywhere on this site.

Who this page is for

Two readers, and they are not asking the same thing

Both get an answer here; the order they read in is different.

Reader one

The team shipping the application

You want findings your engineers can reproduce on the branch they are working on, at a cadence that matches your releases. Start at the phases and the evidence: what a run does, and what lands in the ticket.

Reader two

The buyer who has to file something

You want to know whose signature the report carries and whether it satisfies the obligation you are working to. The delivery models answer the first question, and the regulatory mapping the second.

The run

The six phases, worked against a web application

The phase names are the category’s. What happens inside them is what differs between a scanner and an assessment.

01 Phases one and two

The application is drawn before anything is tested

Discovery
Routes, parameters, roles and the transitions between them, taken from what the application serves.
Client-side analysis
Bundled JavaScript is read for routes, parameters and feature flags the interface never links to. An assessment that only follows links stops at the edge of the menu.
Planning
A mindmap of the application, and a test set written for this application. A payments flow and a document portal are never handed the same list.
02 Phases three and four

Candidates become findings, or they are dropped

Scanning
Broad coverage produces candidates.
Exploitation
A finding survives because it was exploited.
Chaining
What one finding makes reachable is walked. A low-severity disclosure that yields the input to an authentication flow is reported as the chain it enables.
03 Phases five and six

The report, and the gate that can send it back

Reporting
Written up one finding at a time, each reaching your dashboard as it is confirmed.
QA
The sixth phase runs on the finished report and can return it to reporting. It is the phase that rates a finding on what it enables.

The boundary

Three actions wait for your written approval

Everything else inside the authorised scope runs without checking in. The boundary is the same in all three delivery models.

Three actions wait for your written approval
StateWhat it meansWhat follows
Destructive or state-changing actions in production Anything that alters or removes data in a live system, instead of demonstrating that it could be altered. Stops and waits, in writing.
Persistence and movement past the entry host Implants, footholds, and lateral movement beyond the first host reached. Stops and waits, in writing.
Live credentials or real customer data Anything that would use a real account’s credentials or read a real customer’s records. Stops and waits, in writing.
Everything else inside the authorised scope Terminal Mapping, test-case generation, scanning, exploitation, chaining and reporting. Runs without asking.
Key
  • Requires your written approval before B-52 proceeds
  • Authorised by the scope you signed off
  • TerminalNo state follows this one

What approval covers

An approval is for a boundary

Approving persistence for a named scope authorises persistence inside that scope for that engagement. B-52 does not return for a second signature on each instance, and the audit trail records what was permitted, when, and by whom. Where a gate was never released, that is legible too: the record of what was refused is as useful to a reviewer as the record of what was allowed.

What it actually finds

The defect classes a web run returns

Drawn from B-52’s web engagement results. Access control and logic dominate.

ClassWhat it looks like in a real application
Broken object level authorisation A record identifier changed in a request that the server honours, so one account reads another’s data. The response is well formed and the status is 200; nothing about it is anomalous.
Broken function level authorisation An administrative route reachable by a role that the interface never shows it to, usually found because the client-side bundle names it.
Token and session handling A signature that is not verified, an algorithm that can be changed, a token that outlives the session it belongs to, or a claim the server trusts without checking.
Server-side request forgery A parameter that takes a URL and is fetched by the server. In the 2025 edition of the OWASP Top 10 this sits inside Broken Access Control.
Business logic and ordering A multi-step flow completed out of sequence, or by a role that should only be able to start it.
Race conditions The same request submitted concurrently, where the application assumed it would arrive once. Discounts, transfers and one-time actions are where this shows up.
Injection and the rest of the catalogue Worked in full.

Broken object level authorisation

What it looks like in a real application
A record identifier changed in a request that the server honours, so one account reads another’s data. The response is well formed and the status is 200; nothing about it is anomalous.

Broken function level authorisation

What it looks like in a real application
An administrative route reachable by a role that the interface never shows it to, usually found because the client-side bundle names it.

Token and session handling

What it looks like in a real application
A signature that is not verified, an algorithm that can be changed, a token that outlives the session it belongs to, or a claim the server trusts without checking.

Server-side request forgery

What it looks like in a real application
A parameter that takes a URL and is fetched by the server. In the 2025 edition of the OWASP Top 10 this sits inside Broken Access Control.

Business logic and ordering

What it looks like in a real application
A multi-step flow completed out of sequence, or by a role that should only be able to start it.

Race conditions

What it looks like in a real application
The same request submitted concurrently, where the application assumed it would arrive once. Discounts, transfers and one-time actions are where this shows up.

Injection and the rest of the catalogue

What it looks like in a real application
Worked in full.

Why the mapping comes first

A test set written for this application

Every class above except the last needs to know what the application is for. Whether a record belongs to a different tenant, whether a step is out of order, whether a role should reach a route: none of those are decidable from a response alone. That is why the mapping phase runs before the testing phase.

Methodology

The standards we test against, at their current versions

StandardVersion, read 2026-09-13What it carries here
OWASP WSTG v4.2, the current stable release The test procedures, cited as specific tests.
v5.0 is in development and is not cited here until it is stable.
OWASP ASVS 5.0.0, May 2025, 17 categories The verification requirements a finding is mapped to, and the level a scope is agreed against.
The first major release in six years; 4.0.3 is superseded.
OWASP Top 10 2025 edition The category each finding is reported under.
Superseded the 2021 edition in January 2026.
PTES Current The engagement structure: scoping, authorisation, and the shape of the report.

OWASP WSTG

Version, read 2026-09-13
v4.2, the current stable release
What it carries here
The test procedures, cited as specific tests.

v5.0 is in development and is not cited here until it is stable.

OWASP ASVS

Version, read 2026-09-13
5.0.0, May 2025, 17 categories
What it carries here
The verification requirements a finding is mapped to, and the level a scope is agreed against.

The first major release in six years; 4.0.3 is superseded.

OWASP Top 10

Version, read 2026-09-13
2025 edition
What it carries here
The category each finding is reported under.

Superseded the 2021 edition in January 2026.

PTES

Version, read 2026-09-13
Current
What it carries here
The engagement structure: scoping, authorisation, and the shape of the report.

How a level is agreed

Scope is agreed against a verification level

What is fixed before a run starts As of 2026-09-13
  • The targets, by hostname and by application, written down and signed off.
  • The ASVS level the assessment is worked to, which sets the depth and not the breadth.
  • The roles that will be tested, and a credential for each.
  • Whether a production system is in scope, which decides how the first of the three approval gates applies.

Deliberately excluded

  • Physical, hardware and wireless testing, which are out of scope for the platform in every class.
  • Denial of service, which is not performed against a production system.

Per finding

What arrives with every finding

Always

The request and the response

Verbatim, as sent and as returned, with the part that proves the defect marked.

Always

Steps that reproduce it

Written so your engineer can run them without asking us anything first. A finding they cannot reproduce still costs them a week.

Always

The classification

Severity with its CVSS vector, the CWE, and the OWASP category at the current edition of the standard.

Fully autonomous only

An independent automated cross-check

In the model with no auditor in it, findings pass a second automated gate before they are reported. It is a check on top of the exploit.

Filing

What a web assessment is evidence for

The delivery model decides whether the output can be filed.

ObligationWhat it asks for, and which model produces it
A periodic application security assessment Any of the three models covers the testing. Where the filing names an empanelled auditor, take the expert-verified or human-led model.
Assessment after a significant change The release-triggered cadence is the point of continuous assessment: a run on the build.
Evidence of remediation Each finding carries through open, fixed, retested and closed, and closes on a retest that cannot reproduce it.

A periodic application security assessment

What it asks for, and which model produces it
Any of the three models covers the testing. Where the filing names an empanelled auditor, take the expert-verified or human-led model.

Assessment after a significant change

What it asks for, and which model produces it
The release-triggered cadence is the point of continuous assessment: a run on the build.

Evidence of remediation

What it asks for, and which model produces it
Each finding carries through open, fixed, retested and closed, and closes on a retest that cannot reproduce it.

On empanelment

Who can sign it

CERT-In empanelment attaches to Security Brigade, and it is a condition of the testing itself, not only of the vendor who sells it. That is why the fully autonomous model’s output is not signable under it and the other two models’ output is. Nothing about the coverage changes between them.

Worked example

What a chain looks like when somebody walks it

Each step alone is a row a triage queue would deprioritise. In sequence they are the reason the assessment was bought.

A chain with each step read alone and then in sequence
LinkAloneIn sequence
1 A route named in the client bundle A path string in minified JavaScript.It names an administrative export the interface never shows a standard user.
2 A role check that is not there An endpoint that answers an ordinary session.A standard user’s session calls the export and gets a file back.
3 An identifier the server honours A numeric parameter in the export request.Changed by one, it selects a different organisation’s export.
4 A file that should not exist for this user A CSV download.Another tenant’s customer records, produced by a feature built for administrators.
A chain with each step read alone and then in sequence Severity sorting answers which finding is worst on its own. It does not answer how somebody got in.

Measured

Benchmarked against our own assessors

B-52 was run in parallel with Security Brigade’s expert assessment team, on the same targets, and both sets of findings were counted together. The denominator is the combined set: everything either party found, each item counted once. B-52 reached 90–95% of it, and part of what it reached was absent from the team’s own output, which is why the combined set is larger than either party produced alone.

FAQ

Common questions

Still deciding whether this is the right test? Ask us directly.

Talk to an engineer
Do you need the source code?+
No. A web assessment is worked against the running application, and the client-side code is read from what the application serves. Reading the server-side source is a separate class with its own scope.
How many roles should we provide credentials for?+
Every role whose boundary matters. Authorisation defects are found by holding one role and reaching for another role’s data, so a single credential can only ever find a fraction of them.
Is a single-page application tested differently?+
The mapping is different because the routes live in the bundle, not in the markup, and that is precisely why the client-side analysis phase exists.
Will it test against production?+
Only where you authorise it, and even then destructive or state-changing actions in production are one of the three gates that stop and wait for written approval.
What if a finding cannot be reproduced?+
Then it is not reported. A candidate is either proved by exploitation or dropped.

Where the claims behind this page are stated

The autonomy boundary

Where the human sits in each delivery model, and the three actions that need written approval.

Validation and proof

How a finding is confirmed before it is reported, and what B-52 was measured against.

Other coverage classes

Active Directory APIs Cloud External network Internal network LLM applications Mobile apps Secure code review Social engineering Thick client

One application, one scan, from $500

One scan covers one application or one target. Card payment works without a sales conversation. If the estate is larger than one application, or the report has to carry a signature, book a scoping call instead.

Request a $500 scan Request a scoping call