Modello di minaccia & OWASP ASVS L1 Self-Attestation

Questo modello copre il deployment in produzione di vaulted.fyi inclusi il frontend web, le route API e lo storage Upstash Redis. Copre inoltre la CLI e il server MCP pubblicati nella misura in cui interagiscono con la stessa API.

Fuori perimetro:

• Il dispositivo endpoint dell'utente (browser, OS, estensioni, clipboard, schermo).
• Il canale di comunicazione attraverso cui viene consegnato il link di condivisione (email, Slack, SMS, ecc.).
• La gestione successiva del testo in chiaro da parte del destinatario.
• Vulnerabilità in Vercel o Upstash al di sotto della superficie API che utilizziamo.

Asset primario: il segreto in testo in chiaro. Non deve mai raggiungere il server, persistere al di fuori dei browser del mittente e del destinatario, né essere recuperabile solo dallo stato lato server.

Asset secondari: testo cifrato, IV, contatori di visualizzazioni, timestamp di scadenza e l'integrità e disponibilità del servizio.

Confini di fiducia (in ordine decrescente di fiducia):

1. Browser del mittente — considerato affidabile per il testo in chiaro e la chiave.
2. Browser del destinatario — considerato affidabile per il testo in chiaro e la chiave dopo aver aperto il link.
3. Rete tra client e server — non affidabile; mitigata da TLS 1.3 e dalla scelta progettuale che solo il testo cifrato la attraversa.
4. Server Vaulted (noi) — parzialmente affidabile. Trattato come un archivio passivo di testo cifrato. Il modello di minaccia presuppone che Vaulted stesso potrebbe essere compromesso senza esporre il testo in chiaro.
5. Upstash Redis — stesso livello di fiducia del server. Solo blob cifrati.

Osservatore passivo della rete. ISP, attore on-path con accesso ai metadati TLS. Sconfitto da TLS e dall'assenza di testo in chiaro o chiave sulla rete.

Attaccante attivo sulla rete. Può tentare un attacco MitM. Sconfitto da TLS, HSTS preload e validazione del certificato. Una compromissione TLS riuscita produce comunque solo testo cifrato.

Server compromesso / operatore ostile. Ci includiamo. Non può leggere i segreti memorizzati perché la chiave non arriva mai. Può negare il servizio o modificare il bundle JS servito — trattato nei rischi residui più in basso.

Attaccante non autenticato con un link di condivisione valido. Per design, chiunque abbia il link completo può decifrare. I limiti di visualizzazione, la scadenza e la passphrase opzionale riducono la finestra temporale. È una proprietà deliberata, non un bug.

Attaccante mirato contro uno specifico mittente o destinatario. Può sfruttare il dispositivo endpoint, il canale di consegna o la gestione post-decifratura del destinatario. Al di fuori del controllo di Vaulted; documentato per trasparenza.

• Cifratura client-side AES-256-GCM con IV casuali da 96 bit tramite crypto.getRandomValues.
• Chiavi da 256 bit generate per ogni segreto via crypto.subtle.generateKey; posizionate nel frammento URL, mai trasmesse.
• Key wrapping opzionale con passphrase tramite PBKDF2 (alto numero di iterazioni) e AES-GCM key wrap.
• Applicazione atomica del contatore di visualizzazioni via Redis HINCRBY con cancellazione nella stessa transazione al raggiungimento del limite.
• Scadenza automatica TTL con limite di 30 giorni; nessuna estensione dopo la creazione.
• Rate limiting a finestra scorrevole per IP sugli endpoint di creazione e visualizzazione.
• noindex sulle pagine di visualizzazione /s/[id] per evitare che gli URL dei segreti trapelino tramite le ricerche.
• TLS 1.3 con HSTS preload, header di sicurezza adeguati, nessun log degli IP oltre le finestre di rate limit.

Queste sono decisioni deliberate sui confini del perimetro, documentate affinché gli utenti possano decidere se Vaulted si adatta al loro modello di minaccia.

• Compromissione del dispositivo endpoint. Un keylogger, un browser infetto o un'estensione ostile possono leggere il testo in chiaro dopo la decifratura.
• Perdita nel canale di consegna. Se il link di condivisione viene inoltrato, archiviato o citato in un thread di risposta email, quel canale diventa la superficie di attacco.
• Sostituzione mirata del bundle. Un CDN o un edge Vercel compromesso potrebbe servire un JS diverso a un utente specifico. Subresource Integrity e build riproducibili sono mitigazioni parziali e sono nel roadmap.
• Comportamento del destinatario. Una volta decifrato, il destinatario può copiare, fare screenshot o inoltrare.
• Passphrase debole. Se utilizzata, una passphrase debole è attaccabile con brute force da chiunque abbia accesso alla chiave wrapped.
• Coercizione fisica. Al di fuori del perimetro di qualsiasi controllo tecnico.

La matrice seguente mappa l'implementazione di Vaulted rispetto a requisiti selezionati di OWASP ASVS Level 1. Le categorie non applicabili (sessioni, autenticazione, upload di file) sono contrassegnate N/A con una breve motivazione anziché omesse — così l'assenza di una voce non viene interpretata come elusione.

La numerazione segue la struttura ASVS 4.0. L'elenco è selezionato, non esaustivo — l'obiettivo è essere onesti riguardo ai controlli che si applicano in modo significativo a un archivio di testo cifrato senza stato e senza account.

Qualsiasi modifica che influisce su un elemento in questo documento — nuovo endpoint, modifica crittografica, refactoring che coinvolge dipendenze, modifica dell'infrastruttura — deve innescare una revisione di questa pagina nella stessa PR. La versione e la data di pubblicazione sopra verranno incrementate quando il documento viene aggiornato; la versione precedente rimane accessibile nella cronologia git pubblica.