Security, one-way tokens, IP and rate controls
Protect master tokens, signed sessions, server IPs, domains, sensitive fields and request limits.
Guides in this workflow
Follow the guide that matches the exact action, filter, menu change or issue.
Keep all master/profile tokens server-side
Never place reusable credentials in public JavaScript, HTML or mobile binaries.
Understand one-way token hashes
Portal, v1 and v2 tokens are authenticated against stored hashes.
Use short-lived client sessions
Default 600 seconds, bounded 60–900 seconds.
Protect session signatures
Reject modified payloads, invalid signatures, excessive TTL, wrong audience/nonce or expiry.
Use server IP whitelists
Restrict tokens to known backend addresses where possible.
Use allowed-domain metadata
Record the expected portal domain for governance/audit; do not treat it as a substitute for server-side authentication.
Use per-minute rate limits
Visible profiles allow 10–1000, default 120.
Enforce client/contact ownership
Never accept arbitrary customer identifiers in place of authenticated session identity.
Enforce client portal permissions
Profile section selection does not override core contact permissions.
Keep CSRF exclusions narrow
Only the listed server-to-server endpoints are excluded.
Enforce HTTP methods
Session/login/register/reset/upload use POST; reads/downloads use GET as implemented.
Enforce MIME and path controls
Office file internals, approved roots and safe filename responses are validated.
Protect API logs
Logs can contain IPs, endpoints, profile IDs and response codes; restrict access/retention.
Require HTTPS
Deploy all portal/gateway traffic over production TLS.
Rotate credentials by replacement and revocation
Create a new profile/key, update the backend, test, then revoke the old credential.
Understand browser exposure risk
The administrator view explicitly warns that the portal master token must remain in external backend config.