Threat Model

This document outlines the security assumptions and identified threats for PrivyNote.

Trusted Components

The User's Browser: Assumed to correctly implement the WebCrypto API and maintain the privacy of variables in memory.
The Client's Device: Assumed to be free of keyloggers or malware that could intercept the fragment or plaintext.

Compromised Database: If the database is leaked, the attacker only sees tokenHash and ciphertext. Without the key (which is never stored), decryption is computationally infeasible.
Server Administrator / Hosting Provider: The server only acts as a storage relay. No one with root access to the server can read the notes.
Network Eavesdropping: All transmissions should be over HTTPS. Even if HTTPS is stripped, the ciphertext is useless without the key.
Note Link Leaks (Referrer): By using no-referrer, clicking a link inside a decrypted note won't leak the note's own URL to the destination site.

XSS (Cross-Site Scripting): If an attacker can inject JavaScript into the page, they can potentially read the fragment or the decrypted content in memory. CSP is implemented to mitigate this.
Key Leakage by User: If the user shares the link over an insecure channel (like plain email or chat logs), the security depends on the security of those channels.
Phishing: Users might be tricked into entering their secret on a fake version of the site.
Client-Side Storage: We do not use localStorage or sessionStorage to avoid persistence of sensitive data beyond the current session window.

Always run behind HTTPS with valid certificates.
Ensure Docker containers have restricted network access outside the required ports.
Monitor server logs for unusual rate-limiting triggers.