Security at Livqeno

This page describes the controls that exist in our code today, and says plainly where protection is still incomplete. Security reviewers can request the full security whitepaper from security@livqeno.com. Developer-facing detail is in the security and compliance docs.

• Two planes. The control plane (the API) decides whether a participant may publish or subscribe, and signs a short-lived token that says so. It never carries media. The media plane (the SFU media server and TURN relay) forwards audio and video, accepts control traffic only from the API, and keeps no database of its own.
• Clients never learn a media server’s address from the API. They receive a node name.
• Your backend holds the API key. It mints tokens for users it has already authenticated. The identity in a token comes from your backend, never from the browser.
• Hosting. Postgres is managed by Supabase. The dashboard, docs and website run on Vercel. The API and media services run on [[INFRASTRUCTURE PROVIDER]]. See Subprocessors.

In transit

• Media is always encrypted between your users’ apps and our servers with DTLS-SRTP. WebRTC has no unencrypted mode.
• Signaling and chat run over WSS and the REST API over HTTPS. Our production configuration refuses to start unless public URLs use https:// and wss://. The API sends HSTS (one year, including subdomains).
• Ingest uses RTMPS or WHIP over HTTPS. File storage endpoints must be HTTPS in production.
• The TLS front-end for the API on our current hosting is being completed before general availability.

At rest

End-to-end encryption

End-to-end encryption for media is built but not yet released. Opt-in, per-room encryption is implemented in the upcoming SDK releases for web, Flutter, Android and iOS/macOS, and is still being verified on real devices. Until it ships, our media servers can technically access the media they forward. They do not record or store it unless you turn on recording or broadcasting.

• Dashboard sign-in by email and password (with email verification) or GitHub or Google OAuth. Sessions last 12 hours, live in an httpOnly cookie, and are revoked on sign-out. Sign-in and password reset are rate-limited.
• Two-factor authentication (TOTP) with ten single-use recovery codes. A project owner or admin can require it of every member.
• Suspension takes effect at once. A suspended account’s sessions stop on their next request, and its projects’ API keys stop within 30 seconds. Password reset revokes every session.
• Roles per project: Owner, Admin, Developer and Viewer. Only an Owner can grant Owner.
• API keys are scoped to one project and one environment, shown once and revocable. A revoked key can keep working for up to a minute while caches expire.
• End-user tokens are short-lived (RTC: 10 minutes by default, at most 6 hours; chat: 1 hour by default, at most 6 hours), bound to their audience, revocable early, and can only narrow permissions. Each token type is signed with its own key, and production refuses to start if any two keys match.
• Browser origins. A per-project allowlist of origins is checked for SDK traffic from browsers.
• Our operators have separate platform roles, and every change they make is written to an admin audit log with secrets redacted.

• Every API key and token is tied to one project and one environment. The server reads the project from the credential, never from the request body. Development and production data are never served across environments.
• Our database provider’s public data API is turned off for every table, with row-level security on and public grants revoked.
• Media tokens bind a room. The media server forwards only to participants authorised for that room.

Isolation is enforced in our application code, not by per-tenant database policies, and all customers share the same infrastructure. We do not offer dedicated or single-tenant deployments.

• Every webhook delivery is signed with HMAC-SHA256 over a timestamp and the body. Reject deliveries older than 5 minutes.
• We refuse to send webhooks to private or internal network addresses. The check runs when the connection is made.
• Failing endpoints are retried with backoff and disabled automatically.

• Project audit log of key, member, webhook and project changes, with actor, IP address and user agent. There is no API to edit or delete entries, and the database refuses updates and deletions. A failed write is buffered and retried rather than dropped.
• Request logs record one line per request with a request ID. Headers and bodies are never logged.
• Metrics endpoints are protected by a secret in production. Health checks cover dependencies, including TURN.

Every change to the platform passes automated checks:

• secret scanning over the full code history;
• dependency review and vulnerability audits for Node, Python and Go, blocking on high severity;
• container image scanning, blocking a release on critical findings;
• weekly automated dependency updates;
• lint, type checks, unit and end-to-end tests.

No external penetration test has been performed yet.

In place: rate limiting, admission control and load shedding, graceful shutdown, webhook retries, idempotency keys, and a managed database with provider backups.

We do not offer an uptime SLA yet. Production runs on a single server today, without redundancy. Monitoring with alerting, a public status page, multi-server and multi-region deployment, and tested backup restores are planned.

We keep a documented incident-response runbook with severity levels and customer notification steps. Under the draft DPA, we will notify affected customers of a personal data breach without undue delay. We can revoke API keys and tokens, suspend accounts, disable webhook endpoints, ban or mute chat users and rotate shared secrets to contain an incident.

• Calls are not recorded or stored. Media is forwarded in memory.
• Chat messages are kept until you delete them or set a retention period. The chat event log is kept 7 days and connection telemetry 30 days.
• Live-stream output (HLS) is public to anyone with the URL. Signed URLs are planned.
• Export and erasure APIs exist for chat data. Call participant and usage records cannot be erased through the API yet.
• See the Privacy Policy and DPA for more.

Email security@livqeno.com. Do not open a public issue. Include the affected component, steps to reproduce, and what an attacker needs and gains.

• We aim to acknowledge reports within 3 business days and confirm or dispute them within 10.
• We publish an advisory after a fix ships, or after 90 days, whichever comes first, and credit you if you wish.
• Safe harbour: good-faith research that tests only your own projects and accounts, does not access other people’s data, avoids denial-of-service and social engineering, and gives us time to fix is authorised. We will not take legal action over it.
• There is no bug bounty.