Customer data security guide
How do you give each customer access only to their own data?
Treat customer separation as a server-side policy applied to every record, query, action, file, export, cache and background process. A login, hidden button or unpredictable identifier is not enough.
The direct answer
After authentication, resolve the user to an active membership in a customer organisation. Use that server-side context to scope every protected query and object lookup, then confirm that the user's role may perform the requested action on the object's current state.
Do not fetch a record by a browser-supplied ID and check its customer afterwards when the data layer can query by both authorised customer and record. Make the safe path the normal path, centralise the policy, and test attempts to cross account boundaries.
01
Model the relationship, not only the user
| Concept | Question it answers | Example |
|---|---|---|
| User | Who authenticated? | A person represented by an identity-provider subject |
| Organisation | Which customer boundary applies? | Company, account, group or legal entity |
| Membership | What is the user's current relationship? | Active member of customer A, invited to customer B |
| Role | Which functions may the member perform? | Viewer, finance user, approver or customer administrator |
| Resource relationship | Does the object belong within the authorised boundary? | Invoice owned by customer A and branch 2 |
| Policy condition | Are additional rules satisfied? | Approval mandate, record state or value threshold |
Users may belong to several organisations. Require an explicit active organisation context and prevent one browser tab or cached response from silently applying the wrong account.
02
Enforce access in a consistent request sequence
- Validate the session or token. Check issuer, audience, signature, expiry and intended authentication flow.
- Resolve current membership. Use server-controlled records rather than accepting a role from request input.
- Select organisation context. Verify that the membership is active and permitted to use the requested portal area.
- Load within scope. Query by authorised organisation and object identifier together.
- Apply action policy. Check role, record state, mandate, sensitivity and any approval rule.
- Return the minimum response. Exclude internal and other-customer fields by design.
- Record significant actions. Audit access changes, exports, approvals and privileged operations proportionately.
03
Make unsafe data access difficult to write
- Require customer scope in repository or service methods that load protected data.
- Use database constraints and relationships to preserve valid ownership.
- Consider database row-level security as defence in depth where it fits the architecture.
- Keep shared reference data separate from customer-owned records.
- Scope search, counts, aggregates, autocomplete and error messages.
- Partition or key cache entries by customer and permission-relevant context.
- Ensure pagination and cursor tokens cannot cross customer boundaries.
- Prevent mass assignment of customer, owner, role and privileged state fields.
- Review reporting replicas, indexes and exports for the same policy.
- Do not leak whether an inaccessible object exists through different errors or timing where that matters.
Centralisation does not mean one giant permission function. Use shared policy concepts and safe data-access abstractions while keeping domain-specific decisions close to the business use case.
04
Authorise files and exports independently
A protected page does not automatically protect a document URL. Every preview, download and export needs a server-side decision tied to the current user, organisation, role and file relationship.
- Store private files outside public executable paths.
- Use server-mediated downloads or short-lived links issued after authorisation.
- Scope document searches, thumbnails, previews and metadata.
- Prevent predictable storage paths from becoming access controls.
- Apply the same policy to generated reports and bulk exports.
- Limit export fields, date ranges, row counts and frequency.
- Protect export jobs, status endpoints and completed download objects.
- Audit sensitive exports and privileged downloads.
- Expire access when membership or account status changes.
- Test copied links after sign-out and with another customer account.
See client portal document management for the wider file lifecycle.
05
Carry customer scope through integrations and background work
A portal can enforce permissions correctly and still leak data through a background export, webhook, shared integration cache or internal support tool. Preserve the authorised customer context as data, not as an implicit global variable.
Jobs
Store scope with the command
Record customer, initiating user, action and authorised object, then revalidate important conditions when work executes.
Source APIs
Request the narrowest data
Use customer-specific filters and service credentials with only the privileges needed.
Webhooks
Verify and remap events
Authenticate the sender, prevent replay and resolve external identifiers to the correct customer safely.
Support
Separate privileged access
Require explicit customer context, least privilege, visible elevation and audit for staff tooling.
06
Test the boundary from an attacker's perspective
| Test | Attempt | Expected result |
|---|---|---|
| Object swap | Replace a record ID with one owned by another customer | No data or action is exposed |
| Organisation swap | Change a customer, branch or tenant parameter | Server rejects or ignores unauthorised context |
| Role escalation | Call an administrator or approval endpoint as a viewer | Function-level authorisation blocks it |
| List leakage | Search, count, filter or paginate across boundaries | Only authorised results and totals are returned |
| File reuse | Open another customer's file URL or a copied expired link | Download is denied |
| Background leakage | Request an export, then change access before completion | Policy and download remain safe |
| Cache confusion | Switch accounts or roles while requesting the same resource | Responses never cross context |
| Support elevation | Use staff tools without the required role or selected customer | Access is denied and recorded |
Automate policy tests for every protected resource type and action. Add regression tests whenever a flaw is found.
07
Customer data isolation review checklist
- Every user maps to explicit organisation memberships and roles.
- Every protected request resolves customer context on the server.
- Every object lookup and list query includes authorised scope.
- Every action applies function and state-level policy.
- Files, exports, search, caches and background jobs follow the same model.
- Internal support access is separate, least-privilege and auditable.
- Account switching clears or partitions customer-specific state.
- Data responses contain only fields the customer needs.
- Cross-customer and privilege-escalation tests run automatically.
- Monitoring can identify unusual denials, exports and access changes.
Connect this focused review to the client portal API architecture, multi-tenant portal design and broader security controls.
Sources
Primary technical sources reviewed
This draft was checked on 21 August 2026 against:
- OWASP API1:2023 Broken Object Level Authorization
- OWASP API5:2023 Broken Function Level Authorization
- RFC 9700: Best Current Practice for OAuth 2.0 Security
- NIST SP 800-207: Zero Trust Architecture
The correct control set depends on the portal's data, transactions, users and threat model. Arrange project-specific security review and testing for sensitive systems.
Questions
Frequently asked questions
How do you ensure customers see only their own data?
Resolve every signed-in user to an active organisation membership and role on the server, then scope every query, object lookup, file request and business action to that authorised context. Test attempts to change customer and record identifiers.
Is a tenant ID in every database table enough?
No. A tenant or customer key is useful, but every data-access path must apply it correctly. Background jobs, reports, exports, caches, search indexes, files and support tools also need the same isolation policy and tests.
Can you trust a customer ID stored in a browser token?
A signed token may carry useful claims, but the API still needs to validate the token and confirm that the user has a current authorised relationship to the requested organisation and object. Do not trust an arbitrary customer ID sent by the browser.
Are UUIDs enough to protect customer records?
No. Unpredictable identifiers can reduce casual guessing, but possession of an identifier is not permission. The server must authorise every object and action.
How should internal support users access customer data?
Use separate, least-privilege support roles with explicit customer selection, visible context, reason capture where appropriate, audit history and controls for any impersonation or elevated access. Do not make support staff ordinary members of every customer account.
Review customer separation
Map the organisations, roles, records and sensitive actions.
LCR can help design and test a customer access model across the portal, APIs, files, integrations and operational support tools.