Plan customer portal permissions with a matrix

“The customer is signed in” does not establish which documents they may read or which orders they may create. A permission plan connects the person acting, the requested action and the data scope concerned.

The following portal is entirely hypothetical. Its companies C10 and C20, roles and checks describe a design, not a completed security test.

From work tasks to the matrix

Here, readers view company documents, order placers can also place orders, and customer administrators manage their company's accounts. The customer administrator role does not automatically inherit all other roles; ordering has not been assigned to it here.

This assignment is an example decision. If customer administrators also need ordering rights, that additional assignment must be explicitly planned and tested. Which company roles they may assign must also be defined. Platform-wide permissions do not follow from this.

Enforce the boundary at the object

Hiding a menu item does not stop a direct document request. The server must check whether the person may act for the selected company and whether the specific document belongs to that permitted scope. A company identifier sent by the browser is a selection, not proof of membership.

The check extends beyond detail pages. Lists, exports and write operations need the same appropriate scope restriction. This design grants no access to combinations that have not been explicitly permitted.

Check permitted and denied paths

The matrix supports expected outcomes before implementation:

• A reader can open a document belonging to their company; placing an order with that role is rejected.

• An administrator from C10 receives no document from C20, even through its direct address.

• Permitted user management changes only own-company accounts and assigns only the roles intended for that purpose.

• After membership or a permission is withdrawn, the protected action remains blocked even with a previously established session.

Test the permitted cases as well as rejected ones. An application that blocks everything does not fulfil the matrix. Record roles, data assignment and expected outcomes for the version being tested.

The matrix clarifies part of the access rules. It replaces neither their technical implementation nor a complete security assessment. Changes to roles, data paths or memberships must feed into the plan and the appropriate checks.

Sources

• OWASP — Authorization Cheat Sheet

• OWASP — Multi-Tenant Application Security Cheat Sheet