Notifications
Clear all
Topic starter
19/08/2026 3:35 pm
TL;DR: Traditional DAST tools miss multi-user flaws because they test applications sequentially, not under concurrent or cross-user conditions, leaving race conditions, broken object-level access, tenant isolation failures, and privilege escalation undetected until production, according to Escape. The practical issue is not scan coverage alone, but whether testing models match modern multi-user authorization behaviour.
NHIMG editorial — based on content published by Escape: Multi-user DAST testing for web application authorization failures
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.
Questions worth separating out
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.
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.
Q: What breaks when tenant isolation is weak in multi-tenant SaaS management?
A: Weak tenant isolation turns convenience into shared risk.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Escape's guide to multi-user DAST testing and authorization failures →
Multi-user DAST testing: are your authorization controls keeping up?
Explore further
19/08/2026 4:16 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Multi-user DAST exposes authorization gaps that single-user scans miss
