Skip to content
cfdemo.link

Security & Compliance: Multi-Layer Edge Defence

Security Model

Section titled “Security Model”

A nostalgic UI doesn’t mean nostalgic security. CF Messenger employs modern defence-in-depth across multiple layers.

Security Layers Snapshot

Section titled “Security Layers Snapshot”
LayerTechnologyPurpose
TransportTLS 1.3 via CloudflareEncrypted in-flight connections
IdentityUUIDv4 Sessions in KVSession validation with 20m TTL
AccessDurable Object GuardsRoom membership verification
Rate LimitingSliding Window (KV)Brute-force and flood protection
Bot ProtectionCloudflare TurnstileNon-interactive CAPTCHA
ContentZod ValidationXSS and injection prevention

Layered Protection

Section titled “Layered Protection”

A nostalgic UI shouldn’t mean nostalgic security. CF Messenger employs a modern security stack:

  1. Session Tokens: UUIDv4 tokens stored in SESSION_KV with 20-minute TTLs, validated on every WebSocket connection.
  2. Private Room Guards: DM room IDs embed sorted participant hashes. Durable Objects verify membership before accepting messages.
  3. Rate Limiting: Sliding windows live inside each ChatRoom DO, with aggregate synchronisation to SESSION_KV.
  4. Transport & CORS: TLS 1.3 enforced by Cloudflare; workers add strict Access-Control-Allow-Origin headers.
  5. Bot Protection: Cloudflare Turnstile gates the login UI, with mandatory server-side siteverify token validation.
  6. Content Safety: Zod validation and string escaping prevent reflected XSS and injection attacks.

Global WAF Shield

Section titled “Global WAF Shield”

By adhering to a standard /api/ path structure, a single set of WAF rules protects the entire *.cfdemo.link zone.

Custom Rules

Section titled “Custom Rules”
  • Zone-Wide Login Protection: Challenges POSTs to /api/auth/login lacking a cfdemo.link referer.
  • Universal API Guard: Blocks access to administrative or system endpoints.
  • Global Hygiene: Blocks automated scanners (curl, python-requests, etc.).

Rate Limiting

Section titled “Rate Limiting”
  • Multi-App Throttling: Hard cap of 5 login attempts per 10 seconds per IP, protecting against brute-force attacks across all subdomains.

Data Residency (UK-Only)

Section titled “Data Residency (UK-Only)”

To demonstrate compliance capability, all Durable Objects and KV namespaces are pinned to the United Kingdom via location_hint.

"durable_objects": {
  "bindings": [
    { "name": "CHAT_ROOM", "class_name": "ChatRoom", "location_hint": "uk" },
    { "name": "PRESENCE_ROOM", "class_name": "PresenceRoom", "location_hint": "uk" }
  ]
}

End-to-End Encryption (Production Roadmap)

Section titled “End-to-End Encryption (Production Roadmap)”

The current proof-of-concept focuses on transport security and access controls. Production deployment will add client-side end-to-end encryption (E2EE):

  • Message Encryption: Megolm session-based encryption, where each message is encrypted on the sender’s device before transmission
  • Device Key Management: Device keys and cross-signing to prevent device spoofing
  • Key Distribution: One-time keys and fallback keys for secure session establishment
  • Key Backup: Encrypted backup of recovery keys in user account
  • Infrastructure Privacy: Like Matrix’s model, CF Messenger infrastructure will never see plaintext messages—only encrypted payloads

This ensures end-to-end encryption operates independently from transport-layer TLS, providing defence-in-depth.

[!NOTE] For plaintext conversations (like this POC), we rely on TLS 1.3 for transport security. For production, clients will encrypt locally, ensuring only message recipients can decrypt.

Compliance & Caveats

Section titled “Compliance & Caveats”

As a Proof-of-Concept: This demo lacks automated GDPR deletion workflows and audit logging (Logpush). It should be treated as a demonstration of technical residency rather than a fully compliant production environment.

Sources & References

Section titled “Sources & References”