Before the second client logs in: test your portal’s access boundaries

An assessment portal can work perfectly for one client and still leave an important question unanswered: what happens when a second organisation uses it?

Imagine a consultancy moving its evidence requests and reviews into a shared application. Each client gets an account. Consultants work across several assignments. A reviewer can approve an assessment but should not change the underlying answers. These are different access requirements, even when everyone uses the same screens.

Before inviting clients, turn those requirements into a demonstration you can review with your development partner. Use invented organisations and synthetic evidence throughout. The exercise below is a practical acceptance aid, not a complete security assessment.

Write the rule before choosing the role

“Clients see their own data” is a starting point. It does not settle whether a client employee may see every assessment in their organisation, whether a subcontractor can download evidence, or who may invite another user.

For one assessment workflow, write down four things: the person’s organisation, their assignment, the resource and the permitted action. A useful rule might be: “A client reviewer may read and approve assessments assigned to them, but may not edit answers or invite colleagues.” Your team must decide whether that is the right rule for its service.

Keep login and permission separate. Login establishes identity; authorisation determines what that identity may do. OWASP recommends granting only necessary access and checking permissions for each request. A hidden button is not an access rule enforced by the server. [1]

Ask for a demonstration with two invented organisations

Prepare a test environment with two entirely fictional organisations, each holding a clearly distinguishable assessment and evidence file. Add a client editor, a client reviewer and a consultant with a deliberately limited assignment. Agree the expected results before the demonstration.

Ask your development partner to walk through five situations:

1. The permitted route works. The editor opens the assessment and evidence they are allowed to use. The reviewer can perform the agreed review action. Record these successful results as well as the restrictions: a broken download is not evidence of correct access control.
2. The other organisation stays inaccessible. Using the first organisation’s account, the developer checks the second organisation’s records and file endpoints in the test environment. The application must refuse access under the agreed rules, even when the resource address is already known.
3. Read access does not become edit access. The reviewer attempts an action reserved for the editor. The server must reject it. Repeat for inviting users if that is restricted to a separate role.
4. The assignment boundary holds. The consultant can work on the assigned assessment but not an unrelated one. If your service deliberately permits wider consultant access, demonstrate that explicit rule instead.
5. A changed permission changes the result. Remove an assignment or reduce a role, then repeat the relevant actions with an existing session as well as a fresh login. Record when the change takes effect and whether that meets your requirement.

OWASP’s testing guide distinguishes checks between users at the same privilege level from checks across privilege levels. The exercise combines both ideas in a consultancy workflow. Have the developer or an authorised tester carry out the technical requests; use no live client data. [2]

Follow the evidence beyond the screen

A portal may produce a spreadsheet export, send a download link or generate a report in the background. Include those routes in your acceptance discussion. A tidy client dashboard tells you little about a file fetched through another route.

For an export, agree which organisation and assignment it covers. Check the resulting file, not only the page that requested it. For a delayed report, ask how the application decides whether the requester is still entitled to the result when it becomes available.

OWASP’s multi-tenant guidance addresses isolation in storage, caches and queued work. It also calls for authorising access before issuing a signed file link and choosing a link lifetime that fits the intended revocation behaviour. [3]

This matters when somebody leaves a project. Removing their portal access does not recall a file they already downloaded. A previously issued download link may also remain usable until it expires. Ask the development partner to demonstrate the actual behaviour and document any delay, rather than promising that every form of access ends instantly.

Make the result part of the handover

Keep a compact record: the agreed rule, the accounts and synthetic records used, the expected result, the observed result and any unresolved difference. Ask which checks will run automatically after software changes.

Include access changes in the operating procedure. NIST explicitly treats granting, changing and withdrawing privileges as part of access management. [4] Agree who can approve a change and how it is recorded.

If a check fails, agree the correction and repeat it before using that workflow with clients. Passing the exercise does not establish that the application is secure in every respect. It gives you evidence about the specific boundaries you agreed to test.

Bring a permission decision to scoping

Choose one assessment, list the people involved and mark what each may read, change, approve, export and share. Highlight the decisions your team has not made yet. That is a useful input to a scoping workshop: a concrete part of your methodology, with boundaries a development team can implement and demonstrate.

Browserbite builds custom software around consultancy workflows. An introductory conversation can establish whether this workflow is a suitable starting point for scoping.

Sources

[1] OWASP, Authorization Cheat Sheet — identity versus permission, least privilege and request-level checks.

[2] OWASP Web Security Testing Guide v4.2, Testing for Bypassing Authorization Schema — horizontal and vertical authorisation tests.

[3] OWASP, Multi-Tenant Security Cheat Sheet — tenant context, file storage, queued work and signed links.

[4] NIST SP 800-210, General Access Control Guidance for Cloud Systems (2020).

Sources checked on 29 September 2026. The worked exercise is an illustrative recommendation; it describes no customer or customer product.