Platform Security Behavior covers the protections the platform enforces automatically — session and cookie handling, browser security headers, redirect and origin checks, MFA rate limits, and the audit trail behind logins. None of these have a settings screen unless noted.
Overview
Beyond the controls you configure on the Security screen, the platform runs a set of protections in the background on every request and every login. These answer the "is the platform doing X?" questions admins and security reviewers typically ask — about cookies, clickjacking, cross-origin access, redirect safety, and abuse protection on MFA. Most of this behavior is fixed; where a toggle exists, it's noted alongside the behavior it controls.
Use Cases
Answer a security review question about how session cookies are protected.
Confirm whether your app or platform can be embedded in someone else's site without your consent.
Check what stops a captured SSO response or a crafted redirect link from being reused.
Understand what happens when third-party cookies are blocked in an embedded scenario.
Set up alerting on failed logins and lockouts via webhooks.
Session and Cookie Protection
Signing in sets a session cookie in the browser; everything a request can do is looked up server-side from that session. Key properties:
The cookie is HttpOnly (page scripts can't read it), Secure (HTTPS only), and SameSite=Lax (browsers won't attach it to cross-site requests, which blocks classic CSRF). No password, token, or user data is kept in browser storage.
The session ID is a long random value — nothing about the user is decodable from it, aside from an internal tenant number embedded for request routing.
Sessions live server-side in fast storage with an automatic time-to-live, backed by a database copy, so they survive infrastructure restarts and can be listed and revoked centrally.
Every API request re-validates the session: unknown, expired, or revoked sessions get a clean 401 and the expired record is purged. A user flagged "must change password" can call nothing but the update-password flow until they comply.
Expiry is sliding for active users: a request landing in the last ~5 minutes of a session's life silently extends it by the full configured duration and refreshes the cookie. Idle sessions lapse on schedule. Duration is set per sign-in method in Settings › Security.
Cookies for Embedded Apps and Guest Sessions
Apps embedded in another site's iframe, and anonymous or guest sessions, get different cookie treatment because the browser sees them as third-party:
Their session cookies are set with SameSite=None plus the Partitioned attribute, so the embedded app works inside the host page while the browser keeps its cookies isolated per embedding site. The per-method "Partitioned Cookies Disabled" toggle in Settings › Security opts out of the Partitioned attribute if a browser mishandles it.
Embedded logins that can't rely on a redirect use a one-shot handoff: the login response carries a short-lived token, about 5 minutes, that the app exchanges exactly once for the session cookie; the token is destroyed on use.
External-session handoffs — where your backend vouches for a user and gets a login URL — use a server-issued session reference that expires quickly, 2 minutes by default and configurable per method, so a leaked handoff URL goes stale almost immediately.
Guest (anonymous) sessions are real sessions with their own expiry; a method can mark them temporary so they last only minutes.
Clickjacking and Framing Protection
Your platform or app can't be embedded in someone else's website unless you allow it. Responses ship with framing denied by default, and mixed content — insecure HTTP resources on an HTTPS page — is blocked. If an app should be embeddable, its Content Security Policy settings, under Application › Settings, list the allowed embedding sites; only those hosts may frame it, and the same list doubles as the app's trusted-domain list for login redirects and cross-origin calls. All traffic is also pinned to HTTPS via HSTS, so browsers refuse to downgrade to HTTP for a year after first contact, subdomains included, and responses forbid content-type sniffing.
Redirect and Origin Validation
The destination you land on after signing in is validated before use. Relative paths are accepted only after strict checks — double-URL-decoding to catch encoded tricks, and rejection of protocol-relative paths and control characters. Absolute URLs must point at the domain you're logging in on, at a globally allowed domain, or, for an app with CSP enforced, at one of that app's trusted domains. Anything else fails with "Invalid redirect url" and no session is handed over. SSO logins add replay protection: each sign-on attempt is single-use, so a captured SSO response replayed later is refused with "This login request has already been used. Please initiate a new login."
Cross-Origin (CORS) Rules
By default the API answers only its own origin — browsers on other sites can't call it with a user's cookies. Cross-origin access is opened deliberately, not globally: login/logout and embed endpoints respond to cross-origin requests only when the calling origin passes an allow-list — the app's trusted domains when it enforces CSP, otherwise a platform-level allowed-origins list — and a disallowed origin gets a flat "Origin not allowed". A sign-in method can add its own gate, an allow-list of request origins checked against every login attempt through that method, so embedded login endpoints can be locked to your own sites. For cross-origin embed scenarios where third-party cookies are blocked entirely, the platform falls back to returning the session as an explicit auth token that the embedded app presents on each call instead of a cookie.
MFA and OTP Abuse Protection
Every MFA/OTP challenge lives in a short server-side session, about 5 minutes, after which the code is useless. On top of that, four independent rate limits guard the flow — each configurable per sign-in method by window, max attempts, and lock duration — covering requesting codes, resending codes, verification calls, and wrong-code entries. Exceeding any of them temporarily locks the user out of MFA with a clear message. Defaults when a policy isn't tuned: about 5 attempts per window, a ~5-minute window, and a lock of 5–30 minutes. Entering wrong codes also burns the challenge itself — after the allowed retries the session is discarded and the user must restart login. All limits are counted server-side per user, so switching devices or IPs doesn't reset them.
Password Encryption in Transit
All traffic is HTTPS end to end. For deployments that want defense in depth — for example, TLS-terminating middleboxes — a password-based sign-in method can be configured with an encryption key so the login form encrypts the password itself before it leaves the browser, and the server decrypts it only at the moment of verification. RSA with modern OAEP padding is the default scheme; AES is also supported. This is a per-method configuration applied by your platform team — nothing changes for end users.
Audit Trail and Alerts
Logins and their failures leave a full trail:
Audit log: every failed login attempt and every account lockout is written as an audit event against the user, alongside the general audit trail of admin changes, including identity provider edits.
User activity reports: successful logins, logouts, failed attempts, and lockouts are captured with timestamp, app, and source IP; last-login is stamped on the user record.
Webhooks: subscribable events fire for user login, user logout, and failed logins, with a payload including the failure reason, username, IP address, and timestamp, so you can stream sign-in activity to a SIEM or alerting channel in real time.
Machine-driven sign-ins through a method marked "Keep External Session" are deliberately excluded from login activity and webhooks to avoid noise.
IP Allowlisting and Rate Limiting
For the platform login screen, brute force is contained by account lockout and MFA rate limits, both per-user and server-side, rather than by IP rules. For APIs you publish through the API Platform module, both exist as attachable policies: IP-based access control — allow-lists and block-lists, single IPs or CIDR ranges, evaluated against the caller's real source address — and rate-limit policies, applied per endpoint, collection, or access profile. There is currently no tenant-wide "only these IPs may log in" setting on the Security screen; the closest controls are per-method login-origin allow-lists (see CORS above) and API Platform IP policies for published endpoints.
Notes
A few things worth knowing before a security review comes up:
Cite the fixed protections — HttpOnly/Secure/SameSite cookies, denied framing by default, HSTS — as always-on, not configurable per app.
Use Content Security Policy settings, not a separate toggle, to make an app embeddable and to trust specific domains.
Route SIEM or alerting integrations through the login/logout/failed-login webhooks rather than polling the Activity report.
Remember IP-based restriction only exists for published APIs, not for the platform login screen itself.
Treat "Keep External Session" logins as intentionally excluded from activity and webhook noise, not as a gap in the audit trail.
Most of this behavior needs no configuration at all — it's worth knowing it's there so you don't build a redundant control on top of it.