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.
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.
Every stage keeps the brand, goal, evidence, permissions, and work history attached.
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.
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.