Search is unavailable right now. Try again in a moment.
Authentication was never the weakness here. The token was signed, the session was live, the role was the right one. What the platform did not ask was whether the tenant behind that session owned the record the request named. The same unasked question turned up again on an export path, and again at the point where a token is issued with a tenant written into it.
The chain, step by step
Each row names the technique, the weakness it maps to and what the step yielded. A finding that hands nothing to the next step is a finding, and the report is where it belongs.
| Step | What it yielded | Severity |
|---|---|---|
| 01 · A record identifier resolved without an owner check | A confirmed read across the tenant boundary, and the identifier format every later step was built on. | High |
| Two tenant accounts were provisioned for the test, so that a boundary existed to try to cross. A detail endpoint on the authenticated application took a record identifier from the request and resolved it against the whole table. The session check ran and passed; the role check ran and passed; neither of them was a tenant check. An identifier belonging to the second tenant, presented on the first tenant’s session, returned that record. (CWE-639, Authorisation bypass through user-controlled key) | ||
| 02 · The same omission on a reporting export | Records from outside the caller’s own tenant returned in one response, carrying the internal tenant identifiers the platform writes into its own rows. | Critical |
| The reporting and export path accepted a filter over the same identifier family, composed its query from it, and applied the same absent ownership constraint. Where the detail endpoint resolved one record per request, the export resolved a result set, and it ran as a server-side job that wrote a file the caller collected afterwards, which put the missing constraint in a background worker as well as in a request handler. (CWE-284, Improper access control) | ||
| 03 · Internal tenant identifiers inside the exported fields | A tenant identifier in the form the platform’s own token claim is written in, which is the difference between the final step and guesswork. | Medium |
| The export was built for operational use inside a tenant, so it carried the row metadata an operator would want: the internal tenant identifier, the owning account reference and the record timestamps. On its own that is a disclosure finding and would be reported and rated as one. In this chain it is the step that supplied a value in the exact internal form the next step needs. (CWE-200, Exposure of sensitive information to an unauthorised actor) | ||
| 04 · A tenant claim trusted as requested | A properly signed session that the application itself treated as belonging to the other tenant: its whole authenticated surface, and not one endpoint at a time. | Critical |
| The session token carried the tenant as a claim, and its signature was verified on every request. The gap was not in the signature. A tenant-switch call, the one a user with access to more than one tenant legitimately uses, accepted the requested tenant identifier as an input and minted a correctly signed token for it without resolving whether the authenticated subject was a member of that tenant. Supplied with the identifier recovered in the previous step, it returned a valid token whose claim named the other tenant. (CWE-287, Improper authentication) | ||
01 · A record identifier resolved without an owner check
Two tenant accounts were provisioned for the test, so that a boundary existed to try to cross. A detail endpoint on the authenticated application took a record identifier from the request and resolved it against the whole table. The session check ran and passed; the role check ran and passed; neither of them was a tenant check. An identifier belonging to the second tenant, presented on the first tenant’s session, returned that record. (CWE-639, Authorisation bypass through user-controlled key)
02 · The same omission on a reporting export
The reporting and export path accepted a filter over the same identifier family, composed its query from it, and applied the same absent ownership constraint. Where the detail endpoint resolved one record per request, the export resolved a result set, and it ran as a server-side job that wrote a file the caller collected afterwards, which put the missing constraint in a background worker as well as in a request handler. (CWE-284, Improper access control)
03 · Internal tenant identifiers inside the exported fields
The export was built for operational use inside a tenant, so it carried the row metadata an operator would want: the internal tenant identifier, the owning account reference and the record timestamps. On its own that is a disclosure finding and would be reported and rated as one. In this chain it is the step that supplied a value in the exact internal form the next step needs. (CWE-200, Exposure of sensitive information to an unauthorised actor)
04 · A tenant claim trusted as requested
The session token carried the tenant as a claim, and its signature was verified on every request. The gap was not in the signature. A tenant-switch call, the one a user with access to more than one tenant legitimately uses, accepted the requested tenant identifier as an input and minted a correctly signed token for it without resolving whether the authenticated subject was a member of that tenant. Supplied with the identifier recovered in the previous step, it returned a valid token whose claim named the other tenant. (CWE-287, Improper authentication)
The environment
A multi-tenant SaaS platform: every customer served by the same application against the same database, with the tenant carried as a field on the row instead of as a separate deployment.
In that architecture the tenant boundary is not a network boundary and it is not a database boundary. It is a predicate (a constraint on a query, and a claim in a token), and a predicate has to be re-asserted on every path that reaches data, including the paths nobody thinks of as paths. A request handler is one. A background export worker is another. The endpoint that issues a token is a third, and it is the one that decides what the other two are allowed to see. The scope for this engagement was the authenticated application, with a credential supplied for each role and two tenant accounts provisioned, because a boundary with nothing on the far side of it cannot be tested. That detail decides what kind of testing reaches this class of defect at all: nothing in the chain that follows is visible to a request that has not signed in, and nothing in it is visible to a session that has only ever seen its own tenant. Every step needs a valid, low-privilege, entirely ordinary user.
Points of view
From no single vantage point does anything in this chain look abnormal, which is why authorisation defects survive monitoring that authentication defects do not.
How it joined up
Read as a list, these are an access-control defect, a disclosure and an authentication defect. Read in order, they are one missing predicate, found three times over.
Triaged as separate tickets, these would be worked in severity order, and the step that decides whether there is a chain at all would be worked last. Step 01 establishes the premise: an identifier supplied by the caller reaches the query unqualified by tenant, which means the boundary is not being enforced at the data layer. Step 02 is that same premise on a path built to return a result set, not a single record, and in a background worker instead of a request handler, which is where crossing the boundary stops being a demonstration and starts being an extraction. Step 03 is the hinge, and it is the lowest-rated row on the page. Internal identifiers inside an operational export are a moderate disclosure on their own terms, and on their own terms they would sit in a backlog behind two Criticals. They are not on their own here. The tenant-switch call in step 04 needs a tenant identifier in a specific internal form; a tester who cannot produce one is guessing at a value, and step 03 hands it over in the form the platform itself writes it. That is what the ordering is for. Not that the last step could not exist without the earlier ones (it is a defect either way), but that the route to it ran straight through the finding nobody would have prioritised.
The four checks
Both halves of authentication were enforced on every path tested. The two questions that were not asked are the two that define a tenant boundary.
| State | What it means | What follows |
|---|---|---|
| Is the caller who the session says they are? | The token signature was verified on every request, at every endpoint reached during the engagement. This check was correct and it stayed correct throughout the chain. | Enforced |
| Does the caller hold the role this operation requires? | Role checks were present and they passed. The caller genuinely held the role for every operation in the chain, inside their own tenant. That is the clause that was never evaluated. | Enforced |
| Does the caller’s tenant own the object this request names? | Not asked. The identifier reached the query as supplied and the query was not constrained by tenant: in the request handler at step 01, and again in the background export worker at step 02. | Absent |
| Is the tenant in this token one the subject belongs to? Terminal | Not asked at the moment the token was issued. The switch took the requested tenant as an input and signed it, which made every signature check downstream both correct and beside the point. | Absent |
What the report carried
Every B-52 finding ships with a reproducible exploit artefact. On a tenant-isolation chain the part that gets read first is the pair of responses, because that is what settles the only argument anyone has about these findings: whether it is really cross-tenant.
| Artefact | What it held on this chain |
|---|---|
| The request as sent | The full request line and headers for each step, with the substituted value set against the original it replaced, so a reader can see that one field changed and nothing else did. |
| Host: app.tenant-one.example. The request that crosses the boundary differs from an ordinary one by a single field value, which is exactly why it has to be shown as sent and not described in a sentence. | |
| The response as returned | The body as the server sent it, for both tenants, so the two can be read side by side. A record belonging to the other tenant is only demonstrable against the record that belongs to yours. |
| Steps to reproduce | Ordered from a clean session: which credential, which tenant, which value to substitute, at which step. Written so the fix can be verified by whoever owns the endpoint, and not only by whoever found it. |
| A CVSS v4.0 vector | Per finding, with the vector printed, not only the score, so a team that disagrees with a rating can see which metric they are disagreeing about. On this chain most of that argument lands on privileges required, because every step needs a valid low-privilege session. |
| A CWE | Per finding. The four here are deliberately not the same one. 639 and 284 are both authorisation failures, but they fail in different code, and one mapping across both would have hidden that the export worker needed a fix of its own. |
| The mapping is what makes the remediation below separable. A single CWE across all four rows produces a single ticket, and a single ticket would have closed the export path by fixing the request handler. | |
The request as sent
Host: app.tenant-one.example. The request that crosses the boundary differs from an ordinary one by a single field value, which is exactly why it has to be shown as sent and not described in a sentence.
The response as returned
Steps to reproduce
A CVSS v4.0 vector
The mapping is what makes the remediation below separable. A single CWE across all four rows produces a single ticket, and a single ticket would have closed the export path by fixing the request handler.
The shape of it
One field value, inside a request that is otherwise entirely legitimate.
The step 01 request is a GET against the record detail path of the authenticated application, carrying the first tenant’s session, with Host: app.tenant-one.example and a record identifier in the path. Replayed unchanged except for that identifier (swapped for one observed on the second tenant’s own session, in the second tenant’s own browser), it answers 200, with the second tenant’s record in the body. No error, no redirect, no additional prompt, nothing a client-side control would have caught. Step 02 is the same substitution moved into a query parameter, against a path that composes a filter instead of resolving a single row, and answered out of band by a file the job writes. Step 04 is a POST carrying a tenant identifier the caller holds no membership of, answered with a signed token that says otherwise. Each belongs in a report as a transcript, not as a sentence, and the reason is practical: a reader with the codebase open can tell from the transcript which layer to open. The first two say the constraint is missing below the handler. The fourth says it is missing above it.
What changed
The order is not the order of severity. It is the order in which one fix stops being quietly undone by the absence of the next.
First
The reporting export was the step that returned a result set instead of a single record, and the one reachable with no further work once the first substitution was known. It was disabled at the route while the rest was worked. This is the only item on this rail that is a stopgap, not a fix.
Then
The durable fix was to stop expressing tenancy as something each handler remembers to add. The constraint moved into the data-access layer, applied to every query that touches a tenant-scoped table, sourced from the server-side session and not from anything in the request, so a handler that forgets now returns nothing, instead of returning somebody else’s row. The export worker resolves its scope the same way: from the session that owns the job, never from the parameters the job was queued with.
Then
The tenant-switch call now resolves membership server side before it mints anything: the requested tenant is checked against the authenticated subject’s memberships, and a subject with no membership receives a refusal instead of a signed token. The claim stayed exactly where it was in the token. What changed is that it became an output of a check instead of an input to one.
Last
Internal tenant identifiers and owning-account references came out of the operational export: step 03 treated on its own terms, not as part of the chain. It is last because it is defence in depth: with the predicate and the claim both fixed, the disclosure no longer leads anywhere. Closing it first would have closed the route without closing the door.
How it was confirmed
A fix that cannot be demonstrated failing before and passing after is a fix nobody can audit. Each row is the test that was run back against the artefact the original finding shipped with.
| The change | What the retest ran |
|---|---|
| Tenant predicate in the data-access layer | The step 01 and step 02 requests replayed from the original artefact, on the same two tenant accounts. A cross-tenant identifier now resolves to nothing; the same-tenant request is unchanged. Both halves matter: a change that breaks legitimate access is not a fix, it is an outage with a security note attached. |
| Export worker scope | The export queued with the original parameters, and the job’s own output read, and not only the endpoint’s response. |
| This is the row most often skipped. The handler and the worker were separate code paths, and a retest against the handler alone would have signed off a background job that still had no constraint on it. | |
| Membership check at token issue | The switch called with a tenant identifier the subject holds no membership of, and refused; then called with one it does hold, and honoured. Both directions, because a check that refuses everything also passes the first half of that test. |
| Fields removed from the export | The export re-run and its columns compared against the response recorded in the finding, confirming the internal identifiers are gone and that nothing an operator legitimately relies on went with them. |
| The chain, end to end | The full sequence attempted again from step 01 on a clean session, to establish that the route is closed at more than one point, not at whichever point turned out to be cheapest to change. |
Tenant predicate in the data-access layer
Export worker scope
This is the row most often skipped. The handler and the worker were separate code paths, and a retest against the handler alone would have signed off a background job that still had no constraint on it.
Membership check at token issue
Fields removed from the export
The chain, end to end
How it ran
The run underneath is the same run the fully autonomous model performs. What the delivery model changes is whose signature the report carries, and on an authorisation chain there is a specific thing the senior auditor’s pass is for.
Deliberately excluded
Behind each of these
Each card is a decision this engagement turned on, and the page on this site that documents how it is made every time, not just this time.
Reading across the boundary was in scope. Writing across it was not, and nothing was attempted that would have altered a record belonging to the second tenant. Where that line sits, and who moves it, is decided before a run and not during one.
ProofRequest, response, steps to reproduce, a CVSS v4.0 vector and a CWE, on every finding in every class. The evidence table above is that standard applied to one chain; this is the standard itself.
ScopeCross-tenant testing needs both accounts named and both authorised, by someone entitled to authorise them. The template this site publishes is the form that conversation takes.
MethodDiscovery through to a quality gate that runs on the finished report and can send it back. The method is the same in all three delivery models; what changes is who signs the output.
ClassThe authenticated surface, the roles behind it and the authorisation decisions between them. That is the half of a web application that an unauthenticated view of it cannot reach.
CadenceA tenancy constraint is the kind of thing a later refactor removes without anything visibly breaking: the query still runs and still returns rows, just more of them than it should. That failure mode is silent, so the check for it has to be repeated.
PipelineB-52 runs in four continuous-integration systems in production (GitHub Actions, GitLab CI, Jenkins and Azure DevOps), and a result can fail a build against a severity threshold you set.
FAQ
Still deciding whether this is the right test? Ask us directly.
Talk to an engineerA scan is one application or one target, and the entry price is $500. A paid trial is $299. Web application testing is one of the five application classes available by request; anything wider than a single target is a scoping call.