Security Specification

Security Architecture & Threat Model

Detailed cryptographic specifications, HTTP header hardening, browser sandbox guarantees, and threat boundary definitions.

1. Cryptographic Transport Security

ShareOnline relies on the WebRTC standard Datagram Transport Layer Security (DTLS) protocol:

Protocol Versions: DTLS 1.2 and DTLS 1.3 negotiated via native browser crypto engines.
Key Exchange: Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange ensures Perfect Forward Secrecy (PFS).
Ciphers: Modern AEAD ciphers including AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305.
Zero Server Access: Encryption keys are maintained exclusively in browser process memory on the two endpoints. Intermediate servers cannot decrypt transmitted packets.

The web application enforces strict security headers configured at the reverse proxy and Next.js engine:

Content-Security-Policy: Restricts script execution to 'self' and verified analytics endpoints; restricts frame embedding with frame-ancestors 'none'.
X-Content-Type-Options: nosniff: Prevents MIME-type sniffing vulnerabilities.
X-Frame-Options: DENY: Mitigates clickjacking attacks.
Referrer-Policy: strict-origin-when-cross-origin: Prevents leaking internal session paths in referrer headers.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload: Enforces HTTPS across all connections.

Files never touch server-side storage infrastructure:

No databases or object storage systems store file chunks.
Signaling records expire after 15 minutes of inactivity or immediately upon transfer completion.
Rate limiting operates in memory using sliding-window timestamp tracking to prevent denial-of-service abuse.

Researchers and operators should understand these boundaries:

Signaling Metadata: Signaling brokers see room codes, SDP descriptions, and IP addresses needed to broker the WebRTC handshake.
Physical Screen Privacy: Room codes and QR codes shown on the sender screen should only be displayed to intended recipients.