Multi-user DAST exposes authorization gaps that single-user scans miss

At a glance

What this is: This is an analysis of why single-user DAST misses multi-user authorization failures, especially tenant isolation breaks, BOLA, race conditions, and privilege escalation.

Why it matters: It matters because IAM and application security teams need testing that validates authorization under real user concurrency, not just endpoint reachability or isolated session flows.

By the numbers:

• In 2024, HackerOne recorded an average of more than 6 reports per month related to multi-user vulnerabilities.

Context

Modern applications assume multiple users, roles, tenants, and concurrent actions. That means authorization cannot be validated correctly with a crawl that only follows one authenticated path at a time, because the security boundary is often defined by user-to-user interaction, not by a single request or endpoint.

This is where traditional DAST models fall short. They can confirm that a page loads or an endpoint responds, but they do not naturally prove that one user cannot access another user’s data, repeat a privileged action from a lower role, or bypass tenant boundaries when state changes under concurrency. The issue sits at the intersection of application security and identity governance, because access control has to hold across users, roles, and sessions, not only within one isolated login.

Key questions

Q: What fails when DAST only tests one user at a time?

A: It misses authorization logic that only breaks when two identities, two tenants, or two roles interact. Sequential crawling can confirm that endpoints exist, but it cannot prove that one user is blocked from another user’s data or that a lower role cannot replay a privileged action. The failure is in the test model, not just the application.

Q: Why do multi-user authorization bugs create so much risk?

A: Because the same defect can expose cross-user data, tenant-to-tenant leakage, or privilege escalation depending on which identity is used. Once server-side authorization is inconsistent, the impact is not limited to one endpoint. It can affect customer confidentiality, administrative integrity, and auditability across the application’s most sensitive workflows.

Q: What are the signs that tenant isolation testing is failing?

A: Look for requests that succeed when the same action is replayed under a different tenant, especially if object IDs can be enumerated or modified. Other warning signs include inconsistent access-denied responses, hidden reliance on client-side tenant values, and endpoints that return data based on URL or parameter changes rather than authenticated identity.

Q: How should teams validate authorization in asymmetric role models?

A: Test both directions. Verify that lower-privilege users cannot reach admin-only actions, and also confirm that higher-privilege users cannot accidentally access lower-role private data or workflows. The useful control is not just a hidden button, but server-side enforcement that survives replay, role switching, and direct request manipulation.

Technical breakdown

Why sequential crawling misses multi-user authorization failures

Traditional DAST is built around a single authenticated actor that explores an application one step at a time. That model works for basic endpoint discovery, but it breaks down when authorization depends on another user’s session, another tenant’s object ownership, or a second request happening before state changes settle. Multi-user flaws often emerge from shared state, replayable requests, and inconsistent server-side checks, so sequential scanning never enters the failure condition. In practice, the scanner can see the endpoint but not the disputed relationship between two identities, which is where the control failure lives.

Practical implication: Run scans with multiple identities and explicit cross-user state changes, not just one authenticated session.

How tenant isolation and BOLA fail in real applications

Broken object-level authorization and tenant isolation failures happen when the application accepts an object identifier or tenant context that is not securely bound to the authenticated user. If tenant scope comes from a request parameter, an enumerable ID, or a client-controlled value, one authenticated user may read or modify another user’s data by replaying the same action with a different identity. This is especially common in SaaS platforms where users share similar screens and roles but must still remain strictly separated by ownership and tenant context.

Practical implication: Bind tenant and object access to server-side identity context and verify every object lookup against that context.

Why role-based privilege escalation needs bidirectional testing

Privilege escalation is not always one-directional. A lower-privilege user may be able to replay an admin action, but higher-privilege users can also accidentally reach data or functions that should remain private to a different role or workflow. That means a single upward test is not enough when permissions are asymmetric. The control question is whether the server enforces role state at the point of action, not whether the UI hides a button. If access logic is only checked in the frontend or in a partial service layer, replayed requests can succeed even when the interface appears protected.

Practical implication: Test both upward and downward permission paths so asymmetric access failures do not slip through one-way scans.

Threat narrative

Attacker objective: The attacker wants to bypass authorization boundaries and reach data or actions reserved for another user, role, or tenant.

1. Entry occurs when an authenticated user reaches a shared application surface that is tested only from one user context.
2. Credential or session reuse lets the scanner or attacker replay the same request with a different identity or tenant context.
3. Escalation happens when server-side authorization fails to enforce object ownership, role state, or tenant boundaries.
4. Impact is cross-user data access, unauthorized administrative action, or tenant-to-tenant leakage in production.

Breaches seen in the wild

• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.
• Tesla Kubernetes cryptojacking 2018: Attackers used Tesla's unprotected Kubernetes console to find AWS credentials in a pod and mine cryptocurrency, RedLock reported in February 2018.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Sequential DAST creates authorization blind spots: a scanner that only walks one user journey cannot prove that access control holds under concurrent or cross-user conditions. That leaves multi-user failures outside the test model even when every endpoint appears covered. For practitioners, the governance question is whether the test plan reflects real authorization behaviour or only single-session navigation.

Multi-user authorization is a role and identity problem, not just a testing problem: the failures described here arise when object ownership, tenant boundaries, or role state are not enforced at request time. That makes this a direct IAM and application security intersection, because identity context must be evaluated at the moment of access. Practitioners should treat broken authorization as a server-side governance gap, not a UI defect.

Bidirectional permission testing should become the default for asymmetric roles: once a system has admin, manager, viewer, or tenant-separated users, one-way scans are structurally incomplete. The named concept here is multi-user authorization drift: the gap between how access is intended to behave for each identity and how it actually behaves under replay, concurrency, or role mismatch. Teams should measure that drift continuously, not assume a single happy-path scan proves control.

Broken tenant boundaries carry compliance and trust consequences: once one customer can reach another customer’s records, the control failure is no longer only technical. It becomes a data segregation and accountability issue that affects contractual trust, privacy exposure, and audit defensibility. The practical conclusion is that tenant separation must be proven under realistic multi-user interaction, not asserted from architecture diagrams.

Modern DAST needs identity-aware test design: the gap in this article is not more crawling, but more faithful identity modelling. When testing ignores user context, it misses the very access decisions that define whether an application is secure. Practitioners should align test design with the application’s real role model, tenant model, and replay behaviour.

What this signals

Multi-user authorization drift: the real security gap is the distance between intended role behaviour and what the server actually permits when identities are replayed across shared workflows. Teams that only validate single-user paths will keep underestimating authorization risk in SaaS and API-heavy applications.

For practitioners, the next step is to treat access control testing as an identity exercise, not a crawl exercise. If tenant ownership, role state, and object access are not all proven under multi-user conditions, the application is not yet demonstrating reliable authorization.

A strong programme will map these scenarios to repeatable tests across the exact role combinations that matter most, then use the results to prioritize remediation in the same places it would review privilege or entitlement drift.

For practitioners

• Configure multi-user scan profiles Use at least two authenticated users with different tenants or privilege levels so the scanner can replay the same business action across identity boundaries.
• Test both horizontal and vertical access paths Verify that users cannot read other tenants’ objects and cannot replay higher-privilege actions from lower-privilege sessions.
• Enforce tenant context server-side Bind tenant and owner scope to authenticated identity, never to query parameters, and validate every object lookup against that server-side context.
• Require bidirectional permission checks Run tests that move upward from standard to privileged roles and downward from privileged to restricted contexts so asymmetric authorization failures are not missed.

Key takeaways

• Single-user DAST can leave serious authorization failures invisible because the defect only appears when identities interact.
• The article’s evidence shows that multi-user vulnerabilities are not rare edge cases, but recurring findings in bug bounty and production testing contexts.
• Teams need identity-aware scan design, server-side tenant enforcement, and bidirectional role testing if they want to catch cross-user access before release.

Key terms

• Multi-User Authorization: Multi-user authorization is the control layer that determines what an AI agent may do for each user across connected tools and workflows. In enterprise settings, it must enforce delegated, scoped permissions, preserve auditability, and prevent the model from directly handling secrets or making uncontrolled access decisions.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Tenant Isolation: Tenant isolation is the practice of separating identities, tokens, sessions, logs, and data so one tenant cannot access another tenant's resources. It can range from full physical or logical separation to carefully controlled shared services with strict tenant-aware policy enforcement.
• Privilege Escalation: An attack technique where a compromised identity, often an NHI with initially limited permissions, exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle controls. It is designed for practitioners who need to connect identity governance to operational security decisions across modern environments.