Matter access across the wrong client

Legal services

A legal practice platform organised documents by matter, each belonging to a client. We were asked whether a user on one matter could reach documents filed under another.

Web & API penetration test, Legal practice platform, severity HIGH, reported 2025

At a glance

• Challenge. Document access checked for a valid session but not matter membership, so walkable references could reach files sealed to another client.
• Approach. Using accounts scoped to different matters, we checked whether reads, search, export, versions and attachments enforced membership on the object.
• Result. Matter membership is now enforced on the resolved document, with search, export and version history under the same check, and the surface was retested.
• Impact. A user on one matter could have read privileged documents filed under another client's matter, the kind of exposure that ends engagements and triggers obligations.
• Classification. CWE-639 Authorization Bypass Through User-Controlled Key, OWASP Top 10 (2021): A01 Broken Access Control. Component: Matter document access.

The challenge

Privilege, in the legal sense, depends on strict separation of who can see what. A platform that stores matters for many clients carries that separation as an access check on every document. When the check confirms a valid session but not membership of the matter, the separation exists on the org chart and not in the software.

The identifiers make the gap usable. A matter or document referenced by a sequential value can be walked, and each value that returns content is a file that was meant to be sealed to one client. The interface never offers these documents, but the interface is not the boundary.

For a legal practice, a single privileged document reaching the wrong party is not a data point, it is the kind of event that ends engagements and triggers obligations.

Our approach

We used accounts scoped to different matters and asked, for each document action, whether membership of the matter was enforced on the object or only on the request.

Around the central finding we checked the surface that shared the assumption:

• Whether document reads enforced matter membership, not just a session
• Whether search and export respected the same boundary
• Whether version history and attachments carried the check
• Whether references were enumerable, making any gap systematic

Delivered with the accounts and references used, so each finding could be reproduced against a test practice without taking our word for it.

From finding to fix

1. Scoped accounts to different matters
2. Requested a document from another matter
3. Read a file sealed to another client
4. Enforced matter membership, retested

The outcome

Matter membership is now enforced on the resolved document rather than on the session, and search, export and version history were brought under the same check, so a user reaches only the matters they belong to.

We retested the document surface after the fix. Reported as HIGH in 2025. Retest included in the engagement.

Check your own system

• Create two users on different matters and request each other's document identifiers directly, bypassing the interface.
• Enforce matter membership on the document the server resolves, not on the session or the route that requested it.
• Run the same cross-matter request against search, export, version history and attachments, and confirm each applies the membership check.
• Use non-sequential identifiers for matters and documents so that any check you miss cannot be walked from one value to the next.

Read more case studies, see Web Application Penetration Testing, or write to hello@yaamlabs.com.