Identity and sessions
First-party authentication uses password hashing, email verification, short access tokens, rotating refresh credentials stored as hashes, SameSite cookies, and CSRF proof for cookie-authenticated mutations.
Opening Indoo…
Review Indoo security practices for TLS, headers, identity, sessions, CSRF, rate limits, tenant scope, provider secrets, audit events, deployment, and disclosure.
First-party authentication uses password hashing, email verification, short access tokens, rotating refresh credentials stored as hashes, SameSite cookies, and CSRF proof for cookie-authenticated mutations.
Indoo's implemented security layers include HTTPS and HSTS at the edge, a content security policy and defensive headers, Argon2id password hashing, short-lived signed access tokens, rotating server-tracked refresh sessions, secure cookie controls, CSRF checks, rate limits, tenant-scoped data access, encrypted provider-secret storage, and audit events.
Verified against the current Indoo product · 2026-08-17For security, the current public standard is shown below.
First-party authentication uses password hashing, email verification, short access tokens, rotating refresh credentials stored as hashes, SameSite cookies, and CSRF proof for cookie-authenticated mutations.
Repository operations apply tenant and brand scope; material writes use authorization, audit context, and idempotency where required.
The deployment uses TLS, HSTS, compression, restrictive headers, private application networking, health checks, bounded logs, immutable releases, and production configuration validation.
For security, the sequence keeps context, ownership, and the next decision visible.
Email [email protected] or [email protected] with a concise description, impact, and safe reproduction steps.
Do not access other people's data, degrade service, use social engineering, or publicly disclose an unresolved issue.
Indoo will validate, prioritize, communicate, and request a safe retest when appropriate.
No SOC 2, ISO 27001, HIPAA, PCI, uptime, data-residency, or other certification claim is made on this page. Request current deployment-specific assurance information.
Answers stay specific to security and the current product boundary.
No. The production design uses short-lived access tokens and rotating server-tracked refresh sessions, with the refresh credential carried in an HttpOnly secure cookie.
Tenant and brand scope are enforced in repository access and integration tokens rather than delegated to an AI model.
Use [email protected] or the instructions at /.well-known/security.txt.