Cómo está protegido este sitio
Una herramienta de seguridad que no es segura no tiene derecho a existir. Esta página explica qué hacemos, y sobre todo cómo comprobarlo sin creernos.
Última actualización:
El diseño es la primera defensa
La decisión de seguridad más importante de este proyecto es que no hay backend. Sin endpoint de subida no hay archivos maliciosos que procesar; sin base de datos no hay datos que filtrar; sin cuentas no hay sesiones que robar ni contraseñas que perder. Categorías enteras del OWASP Top 10 no se mitigan aquí: simplemente no aplican.
Content-Security-Policy
La política empieza en default-src none, lo que obliga a declarar cada permiso de forma explícita: nada se cuela por omisión. No hay unsafe-inline en ninguna directiva, ni para scripts ni para estilos, lo cual condiciona cómo está escrito el código y merece la pena.
La línea que más trabajo hace es connect-src, que solo autoriza a este propio dominio, a la API de contraseñas filtradas y a nuestro contador de visitas. Si una dependencia comprometida intentara enviar tu foto o tu contraseña a cualquier otro sitio, el navegador rechazaría la petición. Eso es defensa en profundidad de verdad: la protección no depende de que nuestro código se porte bien.
La cadena de suministro es el riesgo principal
Si toda la criptografía se ejecuta en tu navegador, un paquete de terceros malicioso podría leer lo que escribes. Ese es el vector que realmente importa, y por eso:
- Hay un presupuesto de dependencias. Cada una nueva hay que justificarla; si son menos de cien líneas, se escriben a mano.
- Los scripts de instalación de paquetes están desactivados, que es la vía más barata para comprometer un equipo de desarrollo.
- No hay ningún recurso de terceros en tiempo de ejecución: las fuentes, los iconos y hasta el programa que cuenta las visitas están alojados aquí. Cero CDN externos, y ningún dominio ajeno puede ejecutar código en esta web.
- Las versiones están fijadas en el fichero de bloqueo y las instalaciones son reproducibles.
- Un script de verificación rompe la construcción si aparece innerHTML, eval, new Function o Math.random en el código.
Criptografía
No hemos escrito criptografía. Todo son primitivas WebCrypto del propio navegador: AES-256-GCM para cifrar, PBKDF2-SHA256 con 600.000 iteraciones para derivar la clave, y sal y vector de inicialización nuevos y aleatorios en cada mensaje. El formato del mensaje lleva su propia versión, de tres bytes con el número de iteraciones incluido, para poder subir los parámetros en el futuro sin romper los mensajes ya enviados. Un mensaje alterado no se descifra: falla la comprobación de integridad de GCM.
Manejo de archivos
- El formato se determina por los bytes reales del archivo, nunca por su extensión ni por el tipo que declara el navegador: los dos son manipulables.
- El análisis ocurre en un Web Worker aislado. Si un archivo malformado provoca un bloqueo, muere el worker y la página sigue viva.
- Hay un límite de tamaño y un tiempo máximo de proceso, para que un archivo diseñado para consumir recursos no pueda congelar la pestaña.
- Tu archivo original nunca se modifica: se genera una copia limpia.
Divulgación responsable
Si encuentras un fallo, cuéntanoslo. Nos interesa especialmente cualquier cosa que hiciera que los datos de una persona salieran de su navegador. Los datos de contacto están en /.well-known/security.txt y nos comprometemos a responder en 72 horas. No hay programa de recompensas todavía, pero sí reconocimiento público si lo quieres.