VANKPA
The short answer
Portal access should follow the work people are authorized to do, not just the pages they can see. Define roles, record ownership, and approval powers before development. Hiding a button is a usability choice; server-side authorization is what protects the underlying action.
Make an access matrix
List roles such as client, account manager, reviewer, and administrator. For each, specify viewing, creating, editing, downloading, and deleting records. Add the organization or account boundary. Two clients with the same role should not automatically see each other's information. The business owner must approve these rules.
Enforce every request
OWASP recommends denying access by default and validating permissions on every request. A portal should apply its rules when information is retrieved or changed, including direct API requests and downloads. Do not rely on navigation visibility or a record identifier being hard to guess. Testing should include attempts outside a user's permitted account.
Handle role changes
Define what happens when a staff member changes responsibilities or a client relationship ends. Review invitations, shared accounts, password recovery, and administrative access. Keep access removal part of the operating process. A forgotten account can outlive the business relationship that originally justified it.
Test the boundaries
Create representative test users and verify allowed and denied actions. Include a reviewer who may approve but not edit, and a client who can see only their own records. Document expected results so later changes can be checked. Access controls reduce risk, but no implementation should be presented as an absolute security guarantee.
When to take the next step
Define access before real client information enters the system. Review it again whenever new roles, organizations, downloads, or administrative features are added. If nobody can confidently explain who may see a record, the issue is a missing business decision as well as a technical implementation risk.
- OwnerApproves matrix
- EngineerEnforces rules
- ReviewerTests boundaries
- AdminReviews access
Adapt these responsibilities to your team and project scope.
Before you start
- Define permissions by action and record.
- Test cross-account access attempts.
- Schedule access reviews and offboarding.
Questions clients ask
Is hiding admin buttons sufficient?
No. Permissions must be enforced where the underlying data and actions are handled.
Who should approve access rules?
A business owner familiar with responsibilities, with technical review of how those rules are enforced.
Sources & context
References checked October 6, 2026. The planning recommendations are VanKpa editorial guidance; individual project requirements vary.
Turn the question into a plan
Discuss your next step.
Bring your current setup and the requirements above to a project conversation.