Log inCreate account

Security and Abuse Controls

Security is a launch requirement because this service exposes public signaling/media endpoints and billable APIs.

1. Threat model

Protect against:

  • stolen customer secret keys
  • participant-token theft
  • cross-project data access
  • API replay
  • webhook SSRF
  • webhook spoofing
  • brute force and credential stuffing
  • room abuse/spam
  • TURN bandwidth abuse
  • resource exhaustion
  • billing replay/double charge
  • malicious metadata/log injection
  • dependency/container compromise
  • accidental secret logging

2. Tenant isolation

Every customer-owned resource must be scoped to a project.

Never fetch a room by room ID alone and assume access.

Pattern:

authenticated project
        +
resource project_id
        =
authorized resource

Service-layer authorization is mandatory even if database queries are already scoped.

Add automated tests that attempt cross-project access for every customer API resource.

3. Secret API keys

Requirements:

  • cryptographically secure random value
  • recognizable prefix such as sk_live_
  • full secret shown once
  • only a secure hash stored
  • constant-time verification
  • revocation support
  • last-used timestamp
  • scopes
  • separate live/test keys
  • audit creation/revocation

Never place secret keys in:

  • Flutter/mobile applications
  • browser JavaScript
  • URLs/query strings
  • analytics
  • logs

4. Participant tokens

rtc_pt tokens must be:

  • short-lived
  • project/room/participant bound
  • revocable where practical
  • high entropy
  • unusable as a management API credential

Prefer opaque hashed tokens for v0.1 because they simplify revocation and one-time/session policies.

The media-engine grant generated by /v1/connect should expire quickly.

5. Authentication for Console

Implemented:

  • no passwords: one-time email links (15 min, single use, confirmed with a POST on a page that names the address) or Google OAuth (state cookie, fixed redirect URI, verified email only)
  • email verified by the sign-in itself
  • opaque API session tokens (hashes stored) inside an AES-GCM encrypted, HttpOnly, SameSite=Lax, Secure cookie; revocable sign-out
  • CSRF: server actions are Origin-checked by Next; state-changing routes are POST only
  • per-IP and per-address sign-in throttling; invitation rate limits
  • owner/admin/member roles enforced by the API on every project call
  • audit log of project and workspace changes with the acting user
  • post-sign-in redirects restricted to same-origin paths

Add MFA before targeting enterprise customers.

6. API rate limits

Apply limits by:

  • source IP
  • project
  • API key
  • endpoint class

Special protection for:

  • /v1/connect
  • participant creation
  • room creation
  • API-key creation
  • login
  • password reset

Rate-limit configuration should be plan-aware.

7. Quotas

Initial quotas:

  • concurrent rooms
  • concurrent participants
  • room creation/minute
  • participant creation/minute
  • maximum participants per room
  • maximum room lifetime
  • metadata size
  • webhook endpoints/project

Quotas protect both infrastructure and billing.

8. TURN abuse

TURN can become an open bandwidth relay if misconfigured.

Requirements:

  • authenticated TURN only
  • time-limited credentials
  • no anonymous relay
  • restrict allowed configuration to RTC use
  • monitor TURN bytes
  • rate-limit suspicious usage
  • alert on sudden TURN percentage/bandwidth increase

9. Webhook SSRF protection

Customer-provided webhook URLs are untrusted.

At endpoint creation and delivery:

  • allow only HTTPS for public SaaS
  • resolve DNS safely
  • block localhost
  • block private IPv4/IPv6 ranges
  • block link-local ranges
  • block cloud metadata addresses
  • prevent redirects to blocked addresses
  • re-check destination after DNS resolution
  • apply connection/read timeout
  • response-size limit

Do not permit a webhook to reach internal PostgreSQL, Redis, admin panels, Docker API, or cloud metadata.

10. Webhook signing

Sign raw body with HMAC-SHA256.

Include:

X-RTC-Webhook-Id
X-RTC-Timestamp
X-RTC-Signature

Prevent replay by documenting timestamp validation and event ID deduplication.

11. Input validation

Validate and cap:

  • room name length
  • external ID length
  • display name length
  • metadata JSON size/depth
  • webhook URL length
  • array sizes
  • expiration limits

Reject unknown oversized payloads early.

12. Logging

Use structured logs.

Redact:

  • Authorization
  • Cookie
  • Set-Cookie
  • API secrets
  • participant tokens
  • media tokens
  • webhook signing secrets
  • password/reset tokens

Never log audio/video media.

13. Database

  • PostgreSQL not exposed publicly
  • unique DB user/password
  • least-privilege service roles when practical
  • encrypted off-host backups
  • periodic restore test
  • financial mutations in transactions
  • immutable wallet ledger
  • idempotency constraints

14. Redis

  • no public exposure
  • authentication where supported
  • bind/internal network only
  • do not store long-lived secrets unnecessarily
  • treat Redis as non-authoritative for money

15. CORS

Management API should not use wildcard CORS.

Server-to-server endpoints do not need broad browser access.

Client connect endpoints may require controlled CORS for Web SDK usage.

Project-configurable origins can be introduced after the initial trusted beta.

16. Media privacy

v0.1 does not record calls.

Store technical metadata only:

  • join/leave time
  • duration
  • quality metrics
  • bytes
  • device/platform class where needed

Do not inspect or persist media content.

17. Encryption

Required:

  • TLS for API/Console/WebSocket
  • WebRTC encrypted media transport
  • encrypted backups
  • encrypted sensitive webhook secrets if recoverable storage is required

18. Supply chain

  • pin container versions
  • pin Go/npm/pub dependencies through lockfiles
  • run dependency/security scanning in CI
  • do not execute untrusted build scripts in production
  • keep base images minimal
  • patch host OS
  • periodically rotate secrets

19. Admin operations

Administrative actions must be audited:

  • credit adjustments
  • account suspension
  • room force-end
  • API key revoke
  • plan changes
  • project quota overrides

Avoid a hidden unaudited super-admin endpoint.

20. Abuse response

Create the ability to:

  • suspend account
  • suspend project
  • revoke all keys
  • prevent new room creation
  • terminate active rooms if necessary
  • block abusive source IPs
  • preserve audit/billing evidence

21. Security launch gate

Do not accept public self-service signup until:

  • cross-tenant tests pass
  • secret redaction verified
  • webhook SSRF tests pass
  • TURN is authenticated
  • API rate limits enabled
  • quotas enabled
  • dependency scan enabled
  • backup restore tested
  • API key rotation/revocation tested
  • participant-token expiry tested