Check a secure client portal by defining who may act on each client’s records, then checking those permissions at the actual request and file boundaries. Review sign-in, account recovery and sensitive changes alongside ordinary document access. Use the worksheet below to make client separation an observable acceptance question rather than a promise attached to a login screen.
Which records should each person be able to use?
Start with a small access map. Identify the client organisation, the people acting for it and the records they need. Distinguish reading a document, uploading a replacement, approving work and administering another user’s access. Give each operation a business reason and an owner who can approve the intended boundary.
OWASP recommends giving users only the privileges needed for their work. Documentation. OWASP recommends denying access by default. Documentation. Apply those principles to a specific portal task. A client contact who needs a project document may not need every account record or the ability to add colleagues. Write the intended distinction before the implementer chooses roles or builds the navigation.
Keep client membership separate from a user’s display name. Ask how the proposed system establishes which organisation a person belongs to, who can change that membership and what happens when a person leaves. Include the effect on existing document access in the evaluation brief.
Does a hidden navigation item establish an access boundary?
OWASP calls for permission validation on every request. Documentation. OWASP includes static resources within authorisation checks. Documentation. Request checks at the actual destination as well as through the interface. A client should encounter the agreed permission decision when requesting a document directly, opening a saved link or attempting a supported operation through the application.
Use two synthetic client accounts with clearly distinct records in the proposed test arrangement. Check permitted access first, then attempt the corresponding cross-client request. The important outcome is the treatment of the intended record and operation, not merely whether a menu item was visible.
OWASP recommends tests against the permissions mapped during design. Documentation. Keep the test inventory tied to the access map. Include changes to client membership, document ownership and role assignment where they affect the portal task. Revisit the map when a new feature exposes another record type or another way to retrieve a file.
An original client-separation acceptance worksheet
Use this practical checklist with the portal’s actual roles and record types. Fill it with synthetic references during a controlled acceptance exercise. It gives the team a common language for allowed, denied and unresolved access decisions.
| Boundary | Proposed example | Evidence to collect |
|---|---|---|
| Client membership | User associated with one fictional client | Membership reference and approved role |
| Permitted record | User opens their client’s document | Requested record and resulting access decision |
| Cross-client record | Same user requests another client’s document | Denial at the actual request boundary |
| File retrieval | Direct download link for a restricted file | Permission result for the relevant user |
| Role change | User loses an approval responsibility | Observed treatment of the affected operation |
| Sensitive change | User updates a protected account detail | Authentication and confirmation steps observed |
| Recovery | User follows the agreed account-recovery route | Intended identity checks and resulting access |
Add the application version, test environment and observation reference to each row. Keep expected behaviour separate from observed behaviour. A check that was not executed should remain visibly unexecuted rather than being inferred from a similar successful example.
Record the business owner of every exception. Shared access between related client organisations, for example, may be legitimate when explicitly approved and implemented. Describe the relationship and its permitted operations rather than allowing a general administrator role to become the default answer to every sharing request.
How should sign-in and sensitive changes be assessed?
OWASP permits email usernames provided the address is verified during sign-up. Documentation. Ask how the proposed registration or invitation process establishes the intended person and client association. Review what the user sees when an invitation is expired, sent to the wrong address or no longer appropriate to their role. Keep the identity and client-membership questions connected.
OWASP requires strong transport for login and subsequent authenticated pages. Documentation. Include the actual login, recovery and authenticated routes in the proposed inspection. Ask the implementer to identify the relevant configuration and demonstrate the intended behaviour in the deployed test arrangement. A certificate on the homepage should not be the only evidence collected for the portal workflow.
OWASP recommends re-authentication before sensitive account changes. Documentation. Decide which account actions are sensitive in the actual service and document the expected confirmation steps. Test a representative action through its normal route, then review how an interrupted attempt is handled. Keep the resulting account state and access decision visible to the acceptance reviewer.
OWASP recommends generic authentication error responses. Documentation. OWASP includes non-existent, incorrect and disabled accounts within that generic-response guidance. Documentation. Review the proposed messages for different failure cases against that guidance. The interface should still help a legitimate user understand the next support step. Put the account-recovery instructions and escalation route within the same usability review as the sign-in form.
Hypothetical example: the saved document link
Imagine a client contact saves a document URL, then later changes organisations. The portal’s dashboard now displays the new organisation correctly, but the old saved link is still available for a test request. This hypothetical case examines the permission boundary after a membership change.
Use fictional organisations and a controlled test file. Establish the user’s initial permitted access, make the agreed membership change and request the saved URL again. Record the actual permission decision and which membership state it used. Keep that observation attached to the tested version.
Then repeat the intended permitted task for the new organisation. The acceptance conversation should consider both isolation and legitimate access, so a fix does not merely prevent everyone from using the portal. Assign any unresolved result to an owner with a clear next investigation step.
What should the handover include?
Retain the access map, client-membership rules, file-retrieval checks and sensitive-action tests together. Identify who administers invitations, handles departures and reviews access changes. Include a support route for a client who cannot reach a record they are authorised to use. Record which support role can investigate the problem without changing the client membership merely to gain access.
Keep the general self-service task selection with customer portals. For the implementation brief, see web development and get started with the client roles, record types and access exceptions the proposed portal needs to support.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.