Zero-trust security for custom customer and partner portals

Zero trust means no request is trusted because of where it came from. Every call proves who is making it and is checked against what that identity may do, every time. For a custom portal that mostly comes down to a few disciplined habits.

Customers, partners and staff should authenticate through separate paths with separate session types. A customer session should be structurally unable to reach a staff route, not merely blocked by an if-statement someone might remove.

Checking that a user is logged in is not authorization. Every read and write should verify that this identity may touch this specific record.

• Scope every query by the caller's account or organization
• Use database row-level security where the platform supports it
• Never accept an account ID from the client without checking it against the session

Vendor API keys, device credentials and service tokens live server side in an encrypted environment store. The browser asks your server to perform an action; it never holds a credential that can perform it directly. Use restricted, least-privilege keys wherever a vendor offers them.

Inbound webhooks are verified by signature before parsing. Public endpoints are rate limited. Inputs are validated against a schema at the boundary, and errors return a generic message while full detail goes to logs.

For sensitive actions (role changes, data exports, anything that moves money or controls a device) log who did it, what they did and what the system decided. That log is what an auditor asks for, and it is what lets you prove what happened during an incident.

None of this replaces SOC 2, HIPAA or GDPR obligations, but it maps cleanly onto them: access control, encryption, logging, least privilege and data subject rights. Building it in from the first commit is far cheaper than retrofitting it before an audit.