Modèle de menaces & auto-attestation OWASP ASVS L1

Ce modèle couvre le déploiement en production de vaulted.fyi y compris son frontend web, ses routes d'API et son stockage Upstash Redis. Il couvre également le CLI et le serveur MCP publiés dans la mesure où ils interagissent avec la même API.

Hors périmètre :

• L'appareil de l'utilisateur (navigateur, OS, extensions, presse-papiers, écran).
• Le canal de communication par lequel le lien de partage est transmis (e-mail, Slack, SMS, etc.).
• Le traitement ultérieur du texte en clair par le destinataire.
• Les vulnérabilités de Vercel ou Upstash en dessous de la surface d'API que nous utilisons.

Actif principal : le secret en clair. Il ne doit jamais atteindre le serveur, persister en dehors des navigateurs de l'expéditeur et du destinataire, ni être récupérable à partir du seul état côté serveur.

Actifs secondaires : le texte chiffré, les IV, les compteurs de consultations, les horodatages d'expiration, ainsi que l'intégrité et la disponibilité du service.

Frontières de confiance (par ordre de confiance décroissante) :

1. Navigateur de l'expéditeur — de confiance avec le texte en clair et la clé.
2. Navigateur du destinataire — de confiance avec le texte en clair et la clé après avoir saisi le lien.
3. Réseau entre le client et le serveur — non fiable ; atténué par TLS 1.3 et le choix de conception selon lequel seul le texte chiffré le traverse.
4. Serveur Vaulted (nous) — semi-fiable. Traité comme un stockage passif de texte chiffré. Le modèle de menaces suppose que Vaulted lui-même pourrait être compromis sans exposer le texte en clair.
5. Upstash Redis — même niveau de confiance que le serveur. Uniquement des blobs chiffrés.

Observateur réseau passif. FAI, acteur sur le chemin ayant accès aux métadonnées TLS. Déjoué par TLS et par l'absence de texte en clair ou de clé sur le réseau.

Attaquant réseau actif. Peut tenter un MitM. Déjoué par TLS, le préchargement HSTS et la validation de certificat. Une compromission TLS réussie ne livre toujours que du texte chiffré.

Serveur compromis / opérateur hostile. Nous y compris. Ne peut pas lire les secrets stockés car la clé n'arrive jamais. Peut interrompre le service ou modifier le bundle JS servi — traité dans les risques résiduels ci-dessous.

Attaquant non authentifié disposant d'un lien de partage valide. Par conception, quiconque dispose du lien complet peut déchiffrer. Les limites de consultations, l'expiration et la phrase secrète optionnelle réduisent la fenêtre. C'est une propriété délibérée, pas un bug.

Attaquant ciblé contre un expéditeur ou un destinataire précis. Peut exploiter l'appareil, le canal de transmission ou le traitement du destinataire après déchiffrement. Hors du contrôle de Vaulted ; documenté par souci d'honnêteté.

• AES-256-GCM côté client avec des IV aléatoires de 96 bits issus de crypto.getRandomValues.
• Clés de 256 bits générées par secret via crypto.subtle.generateKey ; placées dans le fragment d'URL, jamais transmises.
• Encapsulation optionnelle par phrase secrète avec PBKDF2 (nombre élevé d'itérations) et encapsulation de clé AES-GCM.
• Application atomique du compteur de consultations via Redis HINCRBY avec suppression dans la même transaction à la limite.
• Expiration automatique basée sur le TTL, plafonnée à 30 jours ; aucune prolongation après la création.
• Limitation de débit par IP à fenêtre glissante sur les endpoints de création et de consultation.
• noindex sur les pages de consultation /s/[id] afin que les URL de secrets ne puissent pas fuiter via la recherche.
• TLS 1.3 avec préchargement HSTS, en-têtes de sécurité robustes, aucune journalisation d'IP au-delà des fenêtres de limitation de débit.

Ce sont des décisions de frontière délibérées, documentées pour que les utilisateurs puissent décider si Vaulted correspond à leur modèle de menaces.

• Compromission de l'appareil. Un enregistreur de frappe, un navigateur infecté ou une extension hostile peut lire le texte en clair après déchiffrement.
• Fuite par le canal de transmission. Si le lien de partage est transféré, archivé ou cité dans une réponse à un fil d'e-mails, ce canal devient la surface d'attaque.
• Substitution ciblée du bundle. Un CDN ou un edge Vercel compromis pourrait servir un JS différent à un utilisateur précis. Subresource Integrity et les builds reproductibles sont des atténuations partielles et figurent sur la feuille de route.
• Comportement du destinataire. Une fois déchiffré, le destinataire peut copier, capturer en image ou transférer.
• Phrase secrète faible. Si elle est utilisée, une phrase secrète faible est cassable par force brute par quiconque dispose de la clé encapsulée.
• Contrainte physique / coercition. Hors périmètre de tout contrôle technique.

La matrice ci-dessous met en correspondance l'implémentation de Vaulted avec une sélection d'exigences OWASP ASVS niveau 1. Les catégories non applicables (sessions, authentification, envoi de fichiers) sont marquées N/A avec une brève justification plutôt qu'omises, pour que l'absence d'une entrée ne soit pas perçue comme une esquive.

La numérotation suit la structure ASVS 4.0. La liste est sélective, pas exhaustive — l'objectif est d'être honnête sur les contrôles qui s'appliquent réellement à un stockage de texte chiffré sans état et sans compte.

Tout changement qui affecte un élément de ce document — nouvel endpoint, changement cryptographique, refactoring touchant les dépendances, changement d'infrastructure — doit déclencher une révision de cette page dans la même PR. La version et la date de publication ci-dessus sont incrémentées lorsque le document est mis à jour ; la version précédente reste accessible dans l'historique git public.