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.
Editorial analysis by NHI Mgmt Group, based on content published by Escape: “How to Implement Multi-User Testing in DAST: Real-World Examples”.
By the numbers:
- In 2024, HackerOne recorded an average of more than 6 reports per month related to multi-user vulnerabilities.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Single-user DAST can leave serious authorization failures invisible because the defect only appears when identities interact.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:16 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Multi-user DAST exposes authorization gaps that single-user scans miss