Security

1. Security Model — Zero Trust by Default

Access tokens are short-lived JWTs (15-minute TTL). Refresh tokens are long-lived but single-use and rotate on every refresh.

Each access token carries an opaque sessionId. A request is only honoured if that session still exists in the session store and its permission version matches the token — a revoked, logged-out, or stale session fails closed with a generic 401 (no information leak about which check failed).

Refresh-token reuse detection: if a rotated refresh token is replayed (token theft signature), the entire session family is revoked immediately and the user is forced to re-authenticate.

Roles and permissions are read from the server-side session record at request time, never trusted from the (potentially stale) token body.

2. Authentication & Session Handling

Passwords are hashed with bcrypt (per-user salt, adaptive work factor). Plaintext passwords are never stored or logged.

Login and registration endpoints are individually rate-limited to blunt credential-stuffing and brute-force attempts. Oversized credential payloads are rejected before the expensive hash comparison (bcrypt-DoS guard).

Web sessions use httpOnly, Secure, SameSite=Strict cookies — the access token is never exposed to JavaScript, mitigating XSS token theft and CSRF.

Refresh tokens are stored as bcrypt hashes server-side; a database disclosure does not yield usable refresh tokens.

Logout and password change actively revoke the session record so a still-valid access token cannot outlive the action.

3. Data Protection & Encryption

Sensitive personal fields (e.g. identity / KYC attributes) are protected with application-level field encryption backed by a managed KMS key — the database alone never holds readable PII.

Where an encrypted column must still be searchable (e.g. payment-processor customer references), we store a keyed blind index rather than the plaintext, so equality lookups work without exposing the value.

Encryption keys and all application secrets are loaded at boot from a managed secrets manager — never committed to source, never baked into images.

User-uploaded assets are stored in object storage and served via short-lived signed URLs rather than public objects.

4. Authorization & Tenant Isolation

Capability-based access control: every privileged action checks an explicit capability resolved from the validated session, not a coarse role string.

Multi-tenant academy / room data is scoped per owner; cross-tenant identifiers are re-validated on the server so a guessed ID cannot read another tenant's data (IDOR-resistant).

Administrative impersonation is read-only by default and every impersonated request is tagged so it cannot perform silent mutations.

High-impact operations require a multi-party approval record before they take effect.

5. Request Integrity & Abuse Resistance

State-changing endpoints accept an idempotency key so a retried or replayed request cannot double-execute (critical for anything that touches balances or orders).

Input DTOs are strictly validated and size-bounded at the edge; oversized or malformed payloads are rejected before they reach business logic.

WebSocket and real-time channels are authenticated with the same session model as HTTP and are throttled per connection.

6. Auditability

7. Secure Software Supply Chain

Every change is gated by automated pipeline checks before it can reach production:

8. Operational Hardening

Services run as containerised workloads behind a load balancer with health checks; failed instances are rotated automatically.

Error responses fail closed and generic — internal exceptions are not leaked to clients.

Server-side errors surface to users as a transient state rather than a frozen UI, so degraded conditions are visible and recoverable rather than silent.

Secrets are validated at process start; a misconfigured deployment fails fast instead of starting in an insecure state.

9. Responsible Disclosure

10. Continuous Improvement

Security is treated as an ongoing program, not a one-time audit. Active workstreams include service-to-service mutual-TLS, hardware-backed key custody, request fingerprint–based rate limiting, and expanded fuzzing of untrusted input surfaces. We update this page as controls ship rather than describing controls that do not yet exist.