Client portal security guide
How do you secure a client portal?
Secure a client portal by treating identity, customer separation, permissions, data protection, integrations and operations as one system. The most important rule is to authorise every protected request on the server, not only in the interface.
The short answer
A secure client portal needs reliable authentication, explicit organisation and role models, server-side authorisation, tested tenant isolation, protected sessions, encrypted transport, careful handling of files and secrets, auditable high-risk actions, secure integrations, monitored operations and a practical incident process.
The required depth depends on the information and actions involved. A document portal holding personal or financial records needs stronger controls and assurance than a portal exposing low-risk product information. Security requirements should be part of the initial scope, not a final testing phase.
01
Start with the information, actions and likely threats
Before choosing controls, identify:
- the customer, personal, financial and commercially sensitive information involved;
- which actions could move money, change contractual data, disclose documents or affect operations;
- customer organisations, branches, roles, administrators and support users;
- connected systems and the permissions the portal receives from them;
- legal, contractual, retention and notification obligations;
- the impact of unavailable, incorrect or exposed information; and
- how the business will detect, respond to and recover from misuse or compromise.
This creates a security model tied to the portal's actual purpose rather than a generic checklist.
02
Core client portal security controls
| Area | What good looks like | Common mistake |
|---|---|---|
| Authentication | Secure sign-in, protected recovery, session controls and MFA or SSO where risk warrants it | Weak recovery or long-lived sessions undermine strong passwords |
| Authorisation | Every protected request is checked on the server against organisation, role and resource | Relying on hidden links or route names |
| Tenant isolation | Customer boundaries are explicit in models, queries, files, cache and tests | Loading a record by ID before checking its customer |
| Input and output | Validate expected data, encode output and constrain uploads | Trusting browser validation or file extensions |
| Secrets | Credentials are server-side, narrowly scoped, rotated and excluded from logs and source control | Putting API keys in frontend code or shared documents |
| Audit | Important access and actions are attributable, protected and reviewable | Logging everything without retention, context or privacy controls |
03
Design customer separation into every layer
Associate users, records and resources with the correct customer organisation, branch or account.
Define who may view or change each resource and apply those rules consistently on the server.
Fetch data within the authorised tenant boundary rather than loading a global record and checking later.
Test changed identifiers, direct file links, exports, search, background jobs, caches and administrator tools.
Support staff and platform administrators need explicit, limited privileges. If impersonation or assisted access is required, make it visible, time-bound where possible and auditable.
04
Protect data, documents and downloads
- Collect and duplicate only the information needed for the defined customer workflow.
- Use encrypted transport and platform-appropriate encryption for stored sensitive data and backups.
- Authorise the actual file request; do not rely on an unguessable URL.
- Use short-lived signed links where direct object-storage delivery is appropriate.
- Validate upload type, size and content; isolate processing and scan files according to risk.
- Prevent sensitive data from entering client-side analytics, error messages, URLs or routine logs.
- Define retention, deletion, export and backup-restoration processes.
- Review report exports for formula injection, excessive fields and cross-customer leakage.
Privacy obligations depend on the data, role of each party and jurisdiction. The delivery team should confirm applicable legal and contractual requirements rather than relying on a generic portal template.
05
Secure the integration boundary
A signed-in customer should not receive direct credentials for internal systems. The portal's server-side integration layer should translate the authorised request, use a narrowly scoped service identity and return only the permitted information.
Authenticate inbound webhooks, validate payloads, prevent replay where relevant and avoid trusting customer identifiers supplied by another system without mapping them. Store secrets outside source control, restrict environment access and rotate them when exposure is suspected or operational policy requires it.
See the client portal integrations guide for system ownership, synchronisation and failure patterns.
06
Security continues after launch
Change
Patch and review dependencies
Maintain the runtime, framework, libraries and infrastructure using a defined process and test important updates.
Access
Review users and privileges
Remove stale users, confirm customer administrators and review internal privileged access after role or contract changes.
Detection
Monitor meaningful events
Look for repeated failures, unusual access, permission changes and high-risk actions without collecting unnecessary personal data.
Response
Prepare for incidents
Define ownership, containment, evidence preservation, customer communication, restoration and lessons learned.
Backups are only useful when restoration is tested. Logs are only useful when the right people can interpret and act on them.
07
Security review checklist
- Document data classes, high-impact actions and customer roles.
- Test authentication, recovery, logout and session invalidation.
- Enforce server-side resource and action authorisation.
- Test cross-tenant access across pages, APIs, files, exports and jobs.
- Validate uploads and protect stored documents.
- Keep secrets server-side and credentials narrowly scoped.
- Protect state-changing requests and rate-limit abuse-prone routes.
- Return safe errors without exposing sensitive implementation details.
- Audit privileged and high-risk actions with appropriate retention.
- Scan dependencies and test security-sensitive changes.
- Review production configuration and remove debug access.
- Document backup restoration and incident response ownership.
A checklist supports review but does not replace threat modelling, code review, testing or specialist assurance for high-risk systems.
Further technical references
Use the current OWASP Authorization Cheat Sheet for access-control design and testing, and the File Upload Cheat Sheet when the portal accepts customer documents. These references support implementation review; the portal's own risk and requirements still determine the controls.
08
LCR recommendation
Scope security around the customer's real data and actions. Build organisation and permission boundaries first, keep source-system access behind the server, minimise duplicated sensitive data and include support and recovery processes in the product design.
For the broader service and delivery context, see custom client portal development and the B2B portal feature guide.
09
Frequently asked questions
Does every client portal need multi-factor authentication?
Not necessarily, but it is strongly worth considering for portals exposing personal, financial or commercially sensitive information or allowing high-impact actions. The decision should follow risk, user context and available identity controls.
How do you stop one customer seeing another customer's data?
Model customer tenancy explicitly, apply server-side authorisation to every data access and file request, scope queries by the authorised organisation, and test cross-tenant access as a dedicated security requirement.
Is hiding a button enough to prevent an action?
No. Interface controls help users understand their permissions, but the server must independently authorise every protected read and action. A user can bypass or alter browser requests.
Should a portal store data from every connected system?
Only store what the portal needs for its agreed purpose. Prefer authoritative source systems, minimise duplicated sensitive data, define retention and secure any cache or read model to the same standard as the source information.
How often should portal access be reviewed?
Review privileged and customer access on a schedule appropriate to the risk and when relevant events occur, such as staff departures, customer contract changes, administrator changes or suspected compromise.
Secure the workflow, not only the login
Share the users, data, actions and systems involved.
LCR will help identify customer boundaries, high-risk actions, integration permissions and the controls that belong in the first portal scope.