Logging in does not grant access to everything

A valid account is only the starting point

An account can be correctly authenticated and still receive another customer's invoice. The login worked. The decision about access to that invoice did not. This distinction matters in client portals, internal dashboards and platforms shared by several organisations.

Start by writing down the relationship between the account, the requested record and the intended action. A person may belong to one organisation, manage only an assigned group or have read-only access. A generic staff label is rarely enough to describe every boundary.

Review those rules before extending an existing application. New exports, search results, bulk actions and document downloads can introduce paths that the original screen never covered.

Check the request where the data is accessed

Hiding a button helps explain an interface, but the server must still decide whether to accept the request. A copied URL, an older browser tab or a direct API call can reach the same operation without using the visible button.

For example, invoice lookup should combine the requested identifier with the account's authorised scope. The same rule should cover a PDF download and its preview. An unpredictable identifier can be useful, but it does not replace permission checks.

The OWASP authorization guidance recommends least privilege, denial by default and validation on every request. A practical security review turns those principles into checks for the actual roles and records in the application.

Permission changes also need a lifecycle. Removing a role should affect active sessions and background operations as required by the application's policy. The team needs to know when a change takes effect and which cached decisions must be invalidated.

Test the boundaries between accounts

Use separate test accounts with different ownership and permissions. Confirm the allowed action first, then try the equivalent action against a record outside that account's scope. Include view, edit, export and download paths rather than stopping at navigation.

Repeat relevant checks after revocation and with a session opened before the change. Test read-only roles against write operations. Check that denied requests do not leak the record in an error response or in a generated file.

Keep an acceptance record describing the role, action, expected result and observed result. A passing development check does not establish production acceptance. Deployment, real identity-provider behaviour and any untested flows should remain explicit follow-up work in ongoing technical support.

The same care applies to billing and operational platforms. Financial documents and personal records need access decisions that remain clear after the platform grows.