Security Architecture

whoot. is built on a layered security model that protects your conversations from the moment audio leaves your microphone to the moment it reaches your teammates' speakers. Every layer — transport, media, storage, and application — is independently secured.

Defence in Depth

whoot. follows a defence-in-depth strategy. No single security layer is solely responsible for protecting your data. Instead, multiple overlapping controls ensure that a failure in one layer does not compromise the system:

• Transport encryption — All network communication is encrypted using TLS 1.2+ and DTLS
• Media encryption — Voice audio is encrypted end-to-end using SRTP with keys exchanged via DTLS
• Storage encryption — All data at rest is encrypted with AES-256
• Application security — RBAC, MFA, session management, and input validation at every API boundary
• Infrastructure isolation — Tenant data is isolated at the database level with row-level security policies

Transport Encryption (TLS)

Every HTTP request between your browser and whoot.'s servers is encrypted using TLS 1.2 or higher. This applies to:

• Dashboard and documentation pages
• REST API requests and responses
• WebSocket connections for real-time events
• Webhook deliveries to your endpoints (HTTPS required)
• Authentication flows including SSO callbacks

Older protocols (TLS 1.0, TLS 1.1, and SSL) are not supported. All connections must negotiate TLS 1.2 or TLS 1.3.

Media Encryption (DTLS-SRTP)

Voice audio in whoot. is transmitted using WebRTC, which mandates encryption for all media streams. The encryption mechanism works as follows:

1. DTLS handshake — When a WebRTC peer connection is established, a DTLS (Datagram Transport Layer Security) handshake occurs between the browser and the media server. This is the datagram equivalent of TLS, designed for real-time UDP traffic.
2. Key exchange — During the DTLS handshake, cryptographic keys are securely exchanged. These keys are unique to each session and are never reused.
3. SRTP encryption — Once keys are established, all audio packets are encrypted using SRTP (Secure Real-time Transport Protocol). Every audio packet transmitted between your browser and the server is individually encrypted.

This means that even if network traffic were intercepted, the audio content would be unintelligible without the session-specific cryptographic keys.

WebRTC Security Guarantees

WebRTC, the protocol whoot. uses for real-time audio, provides several security guarantees by design:

• Mandatory encryption — Unlike older VoIP protocols, WebRTC does not allow unencrypted media. Encryption cannot be disabled or downgraded.
• Certificate verification — DTLS certificates are verified during connection setup to prevent man-in-the-middle attacks
• Per-session keys — Encryption keys are generated fresh for every session. Compromising one session does not compromise past or future sessions (forward secrecy).
• Browser-enforced — WebRTC security is implemented at the browser level, not in application JavaScript. This means it cannot be bypassed by extensions, scripts, or other client-side code.

Signalling Security

Before media flows, a signalling exchange sets up the connection. whoot.'s signalling layer is secured with multiple controls:

• Encrypted WebSocket transport — All signalling messages travel over WSS (WebSocket Secure), which is WebSocket over TLS
• HMAC-authenticated requests — API requests for voice credentials are signed with HMAC-SHA256 using the user's session token, preventing replay attacks and request forgery
• Time-bound tokens — Signalling credentials include timestamps and are validated within a narrow time window to prevent replay attacks
• Credential rotation — Voice credentials are short-lived and rotated automatically. When a user disconnects or their session ends, credentials are invalidated server-side

ICE Server Authentication

whoot. uses TURN and STUN servers to establish peer connections when direct connections aren't possible (e.g. behind corporate firewalls or NATs). These servers are secured with:

• Authenticated TURN credentials — Each user receives unique, time-limited TURN credentials that are fetched over an authenticated, HMAC-signed API request
• Credential isolation — TURN credentials are scoped per user and cannot be shared or reused across sessions
• Memory clearing — ICE server credentials are cleared from browser memory when the page unloads or the user signs out, preventing credential leakage

Encryption at Rest (AES-256)

All data stored by whoot. is encrypted at rest using AES-256 encryption:

• Database — All database records, including user data, channel configurations, audit logs, and tenant settings
• Recordings — Audio files from recorded channels are encrypted in storage
• Transcripts — AI-generated transcriptions are encrypted alongside their associated recordings
• File storage — Any files uploaded through in-channel messaging

Encryption keys are managed independently from the data they protect, and are rotated according to industry best practices.

Secure Credential Handling

whoot. takes special care with sensitive credentials in the browser:

• In-memory only — Voice credentials (authentication tokens, SIP passwords) are held in JavaScript memory only and are never written to localStorage, sessionStorage, cookies, or IndexedDB
• Cleared on unload — When you navigate away, close the tab, or refresh the page, all sensitive credentials are explicitly nullified from memory
• Cleared on sign-out — When you sign out, all voice sessions are terminated and all credentials are purged immediately
• Obfuscated API endpoints — Credential-fetching API endpoints use obfuscated paths and payloads to resist casual inspection and automated scanning

Input Validation & SSRF Prevention

All user-supplied inputs are validated at the server boundary:

• Cluster ID validation — Voice cluster identifiers are validated against a strict pattern (lowercase alphanumeric and hyphens only, max 64 characters) to prevent SSRF via URL injection
• Tenant slug validation — Workspace slugs are validated to prevent path traversal and injection attacks
• API payload validation — All REST API request bodies are validated against their expected schemas before processing
• Webhook URL validation — Webhook endpoint URLs must use HTTPS and are validated before any deliveries are attempted

Security Headers

whoot. sets standard security headers on all responses:

• Strict-Transport-Security — Enforces HTTPS for all subsequent requests (HSTS)
• X-Content-Type-Options — Prevents MIME-type sniffing
• X-Frame-Options — Prevents clickjacking by blocking framing
• Referrer-Policy — Controls referrer information sent with requests

Next Steps

• Data Privacy & Isolation — How tenant data is isolated and protected
• Authentication Security — MFA, SSO, and session management
• Network Security — TURN/STUN, WebSocket, and API security
• Security & Compliance — Audit logs, access reviews, and compliance frameworks