Modelo de amenazas y autoatestación OWASP ASVS L1

Este modelo cubre el despliegue de producción de vaulted.fyi incluyendo su frontend web, sus rutas de API y el almacenamiento en Upstash Redis. También cubre el CLI publicado y el servidor MCP en la medida en que interactúan con la misma API.

Fuera del alcance:

• El dispositivo del usuario (navegador, sistema operativo, extensiones, portapapeles, pantalla).
• El canal de comunicación por el que se entrega el enlace compartido (correo, Slack, SMS, etc.).
• El manejo posterior del texto plano por parte del destinatario.
• Vulnerabilidades en Vercel o Upstash por debajo de la superficie de API que consumimos.

Activo principal: el secreto en texto plano. Nunca debe llegar al servidor, persistir fuera de los navegadores del remitente y del destinatario, ni ser recuperable solo a partir del estado del lado del servidor.

Activos secundarios: el texto cifrado, los IV, los contadores de vistas, las marcas de tiempo de expiración y la integridad / disponibilidad del servicio.

Fronteras de confianza (en orden decreciente de confianza):

1. Navegador del remitente — de confianza con el texto plano y la clave.
2. Navegador del destinatario — de confianza con el texto plano y la clave tras introducir el enlace.
3. Red entre el cliente y el servidor — no confiable; mitigado por TLS 1.3 y por la decisión de diseño de que solo el texto cifrado la atraviesa.
4. Servidor de Vaulted (nosotros) — de confianza parcial. Tratado como un almacén pasivo de texto cifrado. El modelo de amenazas asume que el propio Vaulted podría verse comprometido sin exponer el texto plano.
5. Upstash Redis — mismo nivel de confianza que el servidor. Solo bloques cifrados.

Observador pasivo de la red. ISP, actor en la ruta con acceso a metadatos de TLS. Vencido por TLS y por la ausencia de texto plano o clave en el cable.

Atacante activo de la red. Puede intentar un MitM. Vencido por TLS, la precarga de HSTS y la validación de certificados. Un compromiso exitoso de TLS sigue revelando solo texto cifrado.

Servidor comprometido / operador hostil. Nos incluye a nosotros. No puede leer los secretos almacenados porque la clave nunca llega. Puede denegar el servicio o modificar el bundle de JS servido, lo que se aborda en los riesgos residuales más abajo.

Atacante no autenticado con un enlace compartido válido. Por diseño, cualquiera con el enlace completo puede descifrar. Los límites de vistas, la expiración y la frase de contraseña opcional reducen la ventana. Es una propiedad deliberada, no un fallo.

Atacante dirigido contra un remitente o destinatario concreto. Puede explotar el dispositivo, el canal de entrega o el manejo del texto plano por parte del destinatario tras el descifrado. Fuera del control de Vaulted; documentado por honestidad.

• AES-256-GCM del lado del cliente con IV aleatorios de 96 bits de crypto.getRandomValues.
• Claves de 256 bits generadas por secreto mediante crypto.subtle.generateKey; colocadas en el fragmento de la URL, nunca transmitidas.
• Envoltorio opcional con frase de contraseña usando PBKDF2 (recuento de iteraciones alto) y envoltura de clave AES-GCM.
• Aplicación atómica del recuento de vistas mediante el HINCRBY de Redis con eliminación en la misma transacción al alcanzar el límite.
• Expiración automática basada en TTL limitada a 30 días; sin prórroga tras la creación.
• Límite de tasa por IP con ventana deslizante en los endpoints de creación y visualización.
• noindex en las páginas de visualización /s/[id] para que las URL de los secretos no puedan filtrarse a través de las búsquedas.
• TLS 1.3 con precarga de HSTS, cabeceras de seguridad robustas, sin registro de IP más allá de las ventanas de límite de tasa.

Son decisiones de frontera deliberadas, documentadas para que los usuarios puedan decidir si Vaulted encaja en su modelo de amenazas.

• Compromiso del dispositivo. Un keylogger, un navegador infectado o una extensión hostil pueden leer el texto plano tras el descifrado.
• Filtración del canal de entrega. Si el enlace compartido se reenvía, se archiva o se cita en un hilo de correo respondido, ese canal se convierte en la superficie de ataque.
• Sustitución dirigida del bundle. Una CDN o un edge de Vercel comprometidos podrían servir un JS distinto a un usuario concreto. La Subresource Integrity y las compilaciones reproducibles son mitigaciones parciales y están en la hoja de ruta.
• Comportamiento del destinatario. Una vez descifrado, el destinatario puede copiarlo, capturarlo o reenviarlo.
• Frase de contraseña débil. Si se usa, una frase de contraseña débil es vulnerable a fuerza bruta por cualquiera que tenga la clave envuelta.
• Coacción / tortura. Fuera del alcance de cualquier control técnico.

La matriz siguiente asigna la implementación de Vaulted a una selección de requisitos de OWASP ASVS nivel 1. Las categorías que no aplican (sesiones, autenticación, carga de archivos) se marcan como N/A con una breve justificación en lugar de omitirse, para que la ausencia de una entrada no se interprete como evasión.

La numeración sigue la estructura de ASVS 4.0. La lista es seleccionada, no exhaustiva: el objetivo es ser honestos sobre los controles que aplican de forma significativa a un almacén de texto cifrado sin estado y sin cuentas.

Cualquier cambio que afecte a un elemento de este documento — nuevo endpoint, cambio criptográfico, refactorización que afecte a dependencias, cambio de infraestructura — debe desencadenar una revisión de esta página en el mismo PR. La versión y la fecha de publicación de arriba se incrementarán cuando se actualice el documento; la versión anterior permanece accesible en el historial público de git.