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 bugs, and the key finding is that concurrency and role interaction reveal whole classes of vulnerabilities.

Why it matters: It matters because IAM and application security teams need testing that validates tenant boundaries, role separation, and request replay across identities, not just endpoint reachability.

By the numbers:

• In 2024, bug bounty platforms like HackerOne recorded an average of more than 6 reports per month related to multi-user vulnerabilities.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Escape's guide to multi-user DAST testing and authorization failures

Context

Multi-user applications create security conditions that single-session testing often fails to exercise. When applications use shared resources, tenant boundaries, and role-based workflows, the real risk is not whether one user can log in, but whether one identity can access another identity's data or privileges under replayed or concurrent conditions.

That gap matters to IAM and application security programmes because access control is only trustworthy when it is tested in the same shape as production traffic. For teams responsible for human and non-human identity governance, the lesson is the same: permission checks that look correct in isolation can fail once multiple sessions, tenants, or roles are introduced.

Key questions

Q: How should security teams test applications for multi-user authorization bugs?

A: They should test the same business workflow with at least two authenticated identities and compare what each user can view, modify, and export. The goal is to prove that the server enforces ownership, role, and tenant boundaries on every request, not just during login or initial navigation.

Q: Why do single-user DAST scans miss broken access control?

A: Because many access control failures only emerge when a request is replayed under a different user, tenant, or permission set. A single-session crawl can confirm reachability, but it cannot prove that the application re-checks identity context correctly across concurrent or cross-user interactions.

Q: What breaks when tenant isolation is weak in multi-tenant SaaS management?

A: Weak tenant isolation turns convenience into shared risk. If identities, logs, or admin actions can bleed across customer environments, MSPs lose the ability to prove accountability, investigate incidents cleanly, or limit blast radius. In practice, the platform becomes a concentration point for operational and compliance failures instead of a control layer.

Q: How should teams verify privilege escalation resistance in web applications?

A: They should replay sensitive actions discovered in privileged sessions using lower-privilege accounts and confirm the server denies them every time. If a request succeeds because the route is known or the payload is valid, the authorization model is too dependent on the client or prior session context.

Technical breakdown

Why sequential crawling misses cross-user access control failures

Traditional DAST tools usually crawl an application as a single user, following links and replaying requests in one authenticated session. That model can validate whether an endpoint exists, but it does not prove whether the application enforces identity-bound access correctly when a second user, tenant, or role is introduced. Broken object-level authorization often only appears when the same request is repeated with different credentials or modified identifiers. In multi-tenant systems, this is the difference between discovering a page and proving the boundary around it.

Practical implication: test the same workflows with at least two distinct identities and confirm that object and tenant checks are enforced server-side.

How privilege escalation appears in multi-user test paths

Privilege escalation in web applications often comes from trust placed in client-side role state, session reuse, or workflow assumptions. A lower-privilege account may replay an action originally discovered through a more privileged session and succeed if the server does not re-evaluate permissions. This is especially common in admin flows, billing actions, and feature gating tied to account age or eligibility. Multi-user testing exposes whether authorization depends on the user who discovered the route or the user who is actually executing it.

Practical implication: verify that every sensitive request is authorised against the current session context, not against prior navigation history or client-supplied role claims.

Why tenant isolation and bidirectional testing need different configurations

Tenant isolation testing checks whether one customer context can reach another customer's data, while bidirectional privilege testing checks whether higher-privilege and lower-privilege users can improperly access each other's resources. These are related but not identical problems. A scan profile that only moves from one direction can miss leakage in the opposite direction, especially in asymmetric permission models. For modern SaaS and API-heavy applications, the control question is whether the application enforces ownership, tenant scope, and role scope consistently across all request paths.

Practical implication: configure both forward and reverse user paths where privilege hierarchies are asymmetric, and validate that scope enforcement is symmetric where it should be.

Threat narrative

Attacker objective: The objective is to use ordinary application workflows to cross tenant or role boundaries and reach data or actions that should remain isolated.

1. Entry occurs when an attacker or test user authenticates normally and discovers workflows that appear valid for one role or tenant.
2. Escalation happens when the same requests are replayed with a different identity, exposing broken object-level access or privilege checks.
3. Impact follows when cross-tenant data, admin actions, or restricted records are successfully accessed, modified, or exported.

NHI Mgmt Group analysis

Single-user security testing is now an incomplete control model for multi-user applications. The core problem is not that DAST is obsolete, but that the threat model has changed. Modern applications are judged by what happens when identities interact, not when one identity is tested in isolation. For IAM and application security teams, the practical conclusion is that testing must validate cross-session, cross-role, and cross-tenant behaviour before release.

Multi-user authorization failures are identity governance failures at the application layer. Broken object-level access, tenant isolation gaps, and privilege escalation all reflect the same governance assumption: that the application will re-check who is acting, not just what was requested. That makes the topic relevant to identity programmes, because the effective control is not only authentication but continuous enforcement of identity scope. The governance lesson is to align access tests with the real privilege graph, not the expected one.

Cross-tenant leakage deserves a named control concept: tenant-boundary drift. This is the condition where access checks look correct in one workflow but break when identifiers, sessions, or roles shift across users. It is especially dangerous in SaaS and API-driven systems because data ownership and user context can diverge quietly. Practitioner takeaway: treat tenant-boundary drift as a distinct failure mode, and test for it as deliberately as you test for authentication bypass.

Bidirectional testing is the right answer to asymmetric privilege models. Many applications leak in one direction only, which means a unidirectional test leaves part of the attack surface untouched. That matters for enterprises with layered roles, shared objects, or admin and non-admin views over the same record set. The field implication is clear: if the permission model is asymmetric, the scan design must be asymmetric too, or coverage will be false comfort.

What this signals

Multi-user testing should now sit alongside authentication and authorization checks in release gates, especially for SaaS, APIs, and any workflow that separates ownership from login state. The practical shift is from asking whether an endpoint is protected to asking whether the same endpoint remains protected when a second identity reuses the path.

Tenant-boundary drift: when request routes, object IDs, and session context diverge, access control can fail without any obvious login weakness. Teams should treat that as a distinct test case and align it with server-side enforcement patterns such as NIST SP 800-53 Rev 5 Security and Privacy Controls and the NIST SP 800-63 Digital Identity Guidelines.

For programmes that also govern non-human identities, the parallel is direct: a credential or token can be valid without being entitled to the object or action it reaches. The control boundary has to follow the identity boundary, not the UI path.

For practitioners

• Run multi-identity scans on the same workflow Replay critical business actions with at least two authenticated users from different tenants or roles, then compare object access, response codes, and returned data fields for divergence. Use the same endpoints and only vary identity context.
• Test tenant ownership at the query boundary Verify that every database and API lookup enforces tenant_id and owner checks server-side, not in the browser or API client. Confirm that identifiers cannot be enumerated to cross customer boundaries.
• Validate privilege checks on replayed admin actions Capture privileged workflows and replay them under lower-privilege sessions to prove the server rejects the request even when the route and payload are known. Focus on billing, exports, role management, and content publication.
• Separate forward and reverse coverage for asymmetric roles Where administrators and standard users can see different resource sets, run bidirectional tests so leakage in the reverse direction is not missed. Use separate profiles when higher-privilege users may also expose lower-privilege private data.

Key takeaways

• Single-user DAST leaves authorization blind spots because modern apps fail at the point where identities intersect, not where they log in.
• Cross-tenant access, privilege escalation, and replayed request abuse are the same governance problem expressed through different workflows.
• Security teams need multi-identity test coverage, server-side ownership checks, and asymmetric scan paths where roles do not behave symmetrically.

Key terms

• Multi-User DAST: Dynamic application security testing that exercises the same application workflows using multiple authenticated identities. It is designed to reveal access control failures that only appear when roles, tenants, or sessions are compared against one another under real request replay conditions.
• 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.
• 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.

What's in the full article

Escape's full guide covers the operational detail this post intentionally leaves for the source:

• Step-by-step multi-user test configurations for tenant isolation, privilege escalation, and bidirectional coverage.
• Concrete YAML examples for browser-based authentication, natural language rules, and scan profile setup.
• Coverage log walkthroughs that show which user performed each request and where access checks failed.
• Remediation guidance for using multi-user testing directly in development and CI/CD pipelines.

👉 The full Escape guide shows the scan setups, coverage logs, and remediation examples in context.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle controls. It helps practitioners connect identity scope, access boundaries, and operational governance across security programmes.