Broken access control sits at number one in the OWASP Top 10:2025, where it maps to 40 CWEs and 32,654 CVEs across 1,839,701 recorded occurrences. The line from OWASP that should stop a product team mid-sprint is this: 100% of the applications tested were found to have some form of broken access control.
Not most. All of them.
Why dashboards concentrate the risk
A multi-tenant SaaS dashboard is where a company’s worst-case data exposure usually lives, because it is the one surface designed to render everything a customer has. The authorisation decision is therefore made hundreds of times per screen, by different developers, over years, and it only has to be wrong once.
The pattern we look for first is not a missing login. It is a present login and an absent object check.
The pattern, concretely
- Object-level authorisation gaps. The endpoint verifies that you are authenticated and that your role may read reports. It does not verify that this report belongs to your tenant. Changing an identifier in the path, the query string or the JSON body returns someone else’s data.
- Export and print routes. The list view is filtered correctly by tenant. The CSV export, the PDF renderer, or the “share” link generator reaches a different code path that was written later and inherits none of that filtering.
- Client-side role enforcement. The administration panel is hidden from the navigation for non-admins. The API behind it accepts their token.
- Token and claim tampering. A JWT carrying a role or tenant claim that is trusted without server-side verification, or verified with an algorithm the server was persuaded to accept.
- Forced browsing. Old routes, staging routes, and internal tooling still mounted in production behind nothing but an unguessable path.
OWASP’s 2025 entry also carries CWE-918, server-side request forgery, into this category. Worth remembering: an SSRF is an access control failure with a network stack attached.
How to test it, rather than assume it
- Create two accounts in two different tenants, and one low-privileged account in each.
- Capture the full request set of a privileged user in tenant A.
- Replay every one of those requests with tenant B’s session, unchanged, and then with identifiers swapped.
- Record every response that is not a denial. Each one is a candidate finding, not yet a finding.
- Repeat the whole exercise against export, webhook, notification and reporting routes specifically, because they are the ones written after the access control model was agreed.
What actually fixes it
Deny by default, and make the authorisation decision impossible to skip rather than merely mandatory. That means enforcing tenancy in a shared data-access layer that every route must pass through, not as a call each developer is expected to remember. Where a query can be scoped by tenant at the source, scope it there. Log denials and alert on patterns.
And write the test. An access control rule with no automated test is a rule that holds until the next refactor.
