Security at SessionForge

All traffic to sessionforge.dev is served over HTTPS with TLS 1.2 or later, enforced by Google Cloud Run's managed load balancer. There is no plaintext HTTP path to the application in production.

WebSocket connections (used for live session streaming) operate over WSS and inherit the same TLS termination. Session cookies use the __Secure- prefix when served over HTTPS.

Credential accounts: Passwords are hashed with bcrypt before storage. Plaintext passwords are never written to the database or logged. Email verification is required before a credentials account can sign in. Sessions use NextAuth v5 JWTs with a 30-day max age.

OAuth: Google and GitHub OAuth are supported as alternative sign-in methods. GitHub OAuth scope is limited to read:user user:email.

Login rate limiting: Credential sign-in is limited to 10 attempts per IP per 15-minute sliding window, enforced at two independent layers (edge middleware and NextAuth authorize()). If Redis is unavailable, the check fails open — users are not locked out due to infrastructure issues. Rate-limited attempts return the same generic error as a wrong password to prevent username enumeration.

API keys: Keys are prefixed sf_live_ and generated from 24 bytes of cryptographically random data (192 bits of entropy). Only the SHA-256 hash of the full key is stored; the plaintext is displayed once at creation and cannot be retrieved afterward.

Password reset: Reset tokens are single-use and time-limited. A usedAt timestamp is recorded on redemption to prevent replay.

Organizations have four roles, evaluated in ascending order of privilege:

Role enforcement is implemented in org-auth.ts via requireOrgRole(). Every org-scoped API route calls this function before privileged operations. Insufficient role returns HTTP 403 with a structured INSUFFICIENT_ROLE error code.

Active session buffer: Frames are appended to an Upstash Redis list keyed by session ID. The list is deleted immediately after successful archive to GCS.

Archived recordings: When a session stops, the buffer is compressed with gzip and written to Google Cloud Storage in asciinema v2 format. GCS encrypts all stored objects at rest by default using AES-256 with Google-managed encryption keys. Customer-managed encryption keys (CMEK) are [Roadmap] for Enterprise.

Playback access control: Playback URLs are short-lived GCS signed URLs with a 15-minute expiry. The GCS bucket is not publicly accessible; all replay requests pass through the authenticated API.

Organizations can configure one or more CIDR ranges (IPv4 or IPv6) permitted to access the dashboard. An organization with no entries allows access from any IP.

Allowed CIDRs are stored in the ip_allowlists table and cached in Redis with a 60-second TTL. The Edge middleware evaluates the requesting IP on every authenticated request. Paths exempt from enforcement: /api/health, /api/webhooks/stripe, /api/auth, /invite, /login, /signup. If Redis errors, the check fails open. Allowlist changes are written to the audit log.

IP allowlisting is available on Team and Enterprise plans.

The database schema supports both OIDC and SAML providers with fields for client ID, client secret, issuer URL, SAML IDP metadata URL, and email domain enforcement. OIDC sign-in is implemented end-to-end with state + nonce in an HttpOnly cookie.

The admin UI for configuring SSO and the full SAML authentication flow are [Roadmap] items targeted for a future Enterprise release. If you have an immediate SSO requirement, contact us.

All production infrastructure is deployed to Google Cloud us-central1 (Iowa, United States): Cloud Run (application), Cloud SQL (PostgreSQL), and Google Cloud Storage (session recordings and logs). Upstash Redis routes to the nearest available region by default.

EU and APAC region options are [Roadmap] for Enterprise customers. For a full list of subprocessors, see /subprocessors.

PostgreSQL: Cloud SQL automated nightly backups are enabled. A weekly GitHub Actions workflow verifies a recent successful backup exists in the last 7 days and fails the job if not. We have not yet run an end-to-end production restore drill; it is on the near-term engineering backlog.

Session recordings (GCS): Eleven nines (99.999999999%) object durability. Object versioning and cross-region replication are [Roadmap] for Enterprise plans.

Redis: Upstash is used as a short-lived cache and recording buffer, not a primary data store. Durable data is flushed to PostgreSQL or GCS before keys expire.

The following actions are recorded to the audit_logs table for all organizations:

• member.invited
• member.removed
• session.started
• session.stopped
• machine.added
• machine.deleted
• sso.login
• sso.fallback
• api_key.created
• api_key.deleted
• plan.changed
• ip_allowlist.updated

Each record captures organization ID, acting user ID, action type, optional target resource ID, metadata, source IP address, and timestamp with timezone.

If you discover a security vulnerability, please report it responsibly before public disclosure.

Email: perry@support-forge.com
Subject: Security: [brief description]

We acknowledge reports within 2 business days and aim to provide an initial assessment within 5 business days. We do not currently operate a formal bug bounty programme, but we will credit researchers by name in release notes unless they prefer to remain anonymous.

See also our machine-readable security.txt.

In the event of a confirmed security incident affecting customer data, we will:

1. Contain — isolate affected systems and revoke compromised credentials
2. Assess — determine scope, affected users, and nature of data involved
3. Notify — affected customers within 72 hours of a confirmed breach
4. Remediate — patch the root cause, rotate secrets, update the audit trail
5. Post-mortem — publish a written summary of findings and corrective actions

For urgent security matters, include "URGENT SECURITY" in the email subject line.

A weekly GitHub Actions workflow runs npm audit at --audit-level=high against the Node.js dependency tree and govulncheck against the Go agent binary. Reports are retained as workflow artefacts for 30 days. Critical findings are prioritised for immediate patching.