Skip to main content
B‑52
Run a 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 rather than from a list.

Run a scan Request a scoping call

Where this sits

Against the two things you already pay for

No vendor is named here. These are categories of work, 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 argument is about what is left afterwards. Every class in the table above that a scanner cannot reach needs something that understands what the application is for — and that is the work the mapping phase exists to make possible.

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 that reveals routes the interface never links to. Single-page applications are in scope as applications rather than 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. A web assessment reports what the application does, not what the perimeter permits.

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 rather than your audit calendar. 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. Start at the delivery models and the regulatory mapping: coverage is identical across the three, and only the signature differs.

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 actually serves rather than from documentation that may be a release behind.
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. Nothing that leaves this phase is a finding, and nothing is reported from it.
Exploitation
Each candidate is proved or dropped. A finding survives because it was exploited, not because a response pattern matched.
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, not as two unrelated rows.
03 Phases five and six

The report, and the gate that can send it back

Reporting
Findings are written up and land in your dashboard as they are confirmed, rather than arriving together at the end.
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 rather than on what it discloses.

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, rather than 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, not for a single action

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

Read from what B-52 returns on web engagements, rather than from a list of what a scanner looks for. 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 rather than in a category of its own.
Business logic and ordering A multi-step flow completed out of sequence, or by a role that should only be able to start it. There is no payload here and no signature to match.
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. It is the part a scanner is genuinely good at, which is why it is not the part that decides whether an assessment was worth buying.

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 rather than in a category of its own.

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. There is no payload here and no signature to match.

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. It is the part a scanner is genuinely good at, which is why it is not the part that decides whether an assessment was worth buying.

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 and why the test cases are generated rather than loaded. It is also why the harness was written to run the practices a senior Security Brigade auditor works through, rather than to run a check list.

Methodology

The standards we test against, at their current versions

A standard cited at a stale version is a dated-content signal, and this is the reader who checks.

StandardVersion, read 2026-09-13What it carries here
OWASP WSTG v4.2, the current stable release The test procedures, cited as specific tests rather than as a guide.
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. SSRF now sits inside Broken Access Control.
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 rather than as a guide.

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. SSRF now sits inside Broken Access Control.

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, not a page count

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 rather than the breadth.
  • The roles that will be tested, and a credential for each. An authorisation defect cannot be found from one role.
  • 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. Not a description of the exchange.

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, not a substitute for it.

Filing

What a web assessment is evidence for

The delivery model decides whether the output can be filed, not the coverage. All three test the same classes.

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 rather than on the calendar.
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 rather than on the calendar.

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 rather than 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 it is walked rather than listed

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

A chain from a web engagement, with each step read alone and then in sequence
LinkAloneIn sequence
1 Config file in a public repository One stray file among millions, in a developer's own account.A credential sits outside the estate.
2 Attribution to the organisation A developer's side project. Not obviously yours.The repository is tied to the organisation.
3 The key is live A key that may be revoked or fake.Read, write and delete all succeed.
4 What the key reaches A storage bucket of unknown value.Months of customer chat logs, still being written to.
5 What sits beside it A container name in a listing.Secret key stores for serverless functions sit beside it.
6 Who the platform speaks as An integration on a vendor's page.It messages your customers from your verified channel.
A chain from a web engagement, 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.

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.

Run a scan Request a scoping call