Use server-side authentication, session-backed authorization, and record-level filtering tied to the user’s verified identity. The portal should never trust browser state alone. After login, map the authenticated user to an email or account key, then query only the rows that match that identity. That keeps access scoped, reduces exposure, and makes the authorization boundary explicit in the application design.
Design the portal around server-side identity checks, not browser trust
The core design principle is that the server must decide what each user can see, and it must do that on every request. After authentication, the application should bind the session to a verified account identifier and use that server-held context to filter records. The browser can request data, but it should never be the source of truth for ownership, entitlement, or record selection.
This is what turns a portal from a generic login screen into a bounded access path. A user can be authenticated and still be blocked from records that belong to another account, tenant, household, or case file. That boundary needs to exist in application logic, in data access logic, and in any API that the portal calls.
Record-level authorization is the practical control here. The application should evaluate the authenticated identity, map it to the correct account scope, and query only rows or objects that match that scope. That pattern is stronger than hiding links or disabling buttons, because client-side controls can be bypassed while server-side filtering cannot.
For portal teams, the main design question is not just “can the user sign in?” but “what exact data scope does this session permit?” If the answer depends on user role alone, that is usually too coarse for customer portals. If the answer depends on account membership, tenant membership, or explicit record ownership, that relationship must be enforced at the data layer as well as in the application.
One useful implementation pattern is to derive the allowed scope once from the verified login and then pass that scope through every downstream query and service call. That reduces the chance of accidental over-fetching, especially when the portal aggregates data from multiple back-end systems or search endpoints. It also makes audit and review easier because access decisions are tied to one consistent identity context.
When this design is missing, the failure mode is often an insecure direct object reference or broken object-level authorization, where a user can change an identifier and reach another person’s data. The fix is not obscurity, pagination, or front-end validation. The fix is to make ownership checks mandatory on the server before any record is returned.
Why record-level filtering is the real authorization boundary
Authenticated access only proves who the user is. It does not prove which records that user may inspect, edit, export, or delete. In a well-designed client portal, authorization must be object-specific, because the same person may be allowed to view one account’s records but not another account’s records, or may be allowed to view summary data but not attachments, billing details, or history.
That distinction matters because portal data usually has mixed sensitivity. Even when two records look similar in the interface, one may contain personal data, financial data, support notes, or regulated history. Server-side record filtering keeps the authorization boundary aligned to the actual data object, not to the convenience of the screen layout.
It also improves resilience when the portal is built on APIs. If the UI asks for a record by ID, the API must independently verify that the authenticated user is entitled to that specific object. A secure portal should therefore treat every object lookup, search result, export, and bulk action as a separate authorization event, not as a one-time permission granted at login.
For teams using shared back-end services, the safest pattern is to evaluate access as close to the data as possible. That means the service or query layer should enforce row-level or object-level constraints, rather than relying on a front-end route, a hidden field, or a client-side access token claim alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Record-level access control is the central portal requirement. |
| V6 — Authentication | The portal must bind access decisions to a verified signed-in identity. | |
| Recommendation — Enforce object-level authorization on every record request and action. Require server-validated authentication before any record lookup. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Access must be enforced by the server for each protected object. |
| AC-6 — Least Privilege | Users should only receive the minimum record scope their role needs. | |
| Recommendation — Apply access enforcement at the service or data layer for each object. Restrict each session to the minimum record scope required. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Portal access should be governed through approved account and object permissions. |
| Recommendation — Review and maintain object-level access rules for portal users. | ||
Practitioner Guidance
What to verify: Confirm that the identity used after login is the same identity used in the record query, and that the query cannot be altered client-side to expand scope. Test direct object references, search endpoints, exports, and any API the portal calls with another user’s record ID.
Common mistake: Teams often protect the page while leaving the API or database query too broad. If the front end hides other users’ records but the back end still accepts arbitrary IDs, the portal is not actually enforcing ownership.
What good looks like: Every data access path derives scope from the verified server session, and every returned record can be explained by an explicit ownership or membership rule. Reviewers should be able to trace why a specific user saw a specific record without inspecting browser state.
Practitioner takeaway: The safest portal design is not “authenticated users can see their dashboard,” but “each request is re-authorized against the specific record being requested.” That is the difference between login and genuine access control.
Related resources from NHI Mgmt Group
- Who should own digital health access design across security and clinical teams?
- How should security teams design RBAC when users need access across multiple functions or projects?
- How should teams design an access gate for an internal challenge or workflow so only invited users can proceed?
- How should security teams design access controls so users do not work around them over time?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
