Seguridad en Clauva
Última actualización: 14 de mayo de 2026
En Clauva, la seguridad de la información es una prioridad. Esta página describe las medidas de seguridad que aplicamos para los datos de los usuarios, incluyendo datos obtenidos mediante integraciones de correo (IMAP) que el usuario conecta voluntariamente, bajo un enfoque de mínimo privilegio y defensa en profundidad.
Esta página resume nuestros controles principales; algunos controles internos adicionales no se publican por razones de seguridad.
Para reportar una vulnerabilidad o un incidente de seguridad, escríbenos a soporte@clauva.app con el asunto "Reporte de seguridad". El canal principal y oficial de soporte es ese correo; Clauva puede habilitar canales adicionales de atención para usuarios activos (por ejemplo, mensajería directa), los cuales se comunicarán por medios oficiales.
1. Autenticación de usuarios
Las contraseñas de los usuarios nunca se almacenan en texto plano. Se aplican algoritmos de hashing seguros (actualmente bcrypt) antes de persistirlas en base de datos.
Clauva aplica requisitos mínimos de seguridad en contraseñas, incluyendo longitud mínima y complejidad (mayúsculas, minúsculas, números y caracteres especiales).
La autenticación en Clauva utiliza tokens JWT. El backend emite un token de acceso (Bearer token) al iniciar sesión, que el frontend gestiona mediante Auth.js. Las sesiones del lado del cliente se mantienen en cookies con los atributos HttpOnly y Secure, lo que impide su lectura desde JavaScript en el navegador. Las peticiones al backend se autentican enviando el token JWT en el header Authorization como Bearer token. Los tokens tienen una duración limitada de aproximadamente 12 horas.
Actualmente, el acceso de usuarios a la plataforma no incluye autenticación de dos factores (2FA); se evalúa su incorporación en versiones posteriores.
Por separado, las cuentas administrativas que usamos en proveedores de infraestructura (Vercel, Railway y Cloudflare) sí tienen 2FA habilitado, para reducir el riesgo de acceso no autorizado a despliegues, bases de datos y almacenamiento. Más detalle en la sección 8.
2. Conexiones seguras
Todo el tráfico entre tu navegador y Clauva se transmite sobre HTTPS. El sitio en clauva.app y el panel en panel.clauva.app utilizan HTTPS forzado; la aplicación envía cabeceras de HTTP Strict Transport Security (HSTS) para inducir a los navegadores a rechazar conexiones no cifradas cuando corresponde.
Las conexiones entre el frontend (Vercel) y el backend (Railway), así como las conexiones a la base de datos PostgreSQL, utilizan SSL/TLS de forma obligatoria.
Se aplican medidas adicionales como configuración de CORS y limitación de solicitudes (rate limiting) para reducir abusos y ataques automatizados.
3. Gestión de secretos y credenciales
Las credenciales sensibles de producción (claves de API, claves de cifrado, cadenas de conexión a base de datos y demás secretos operativos del servicio) se configuran exclusivamente como variables de entorno y secretos en los entornos de despliegue en la nube del servicio, gestionados fuera del repositorio mediante los mecanismos que ofrece cada proveedor de alojamiento.
Para entornos de desarrollo se utilizan variables de entorno separadas con valores de prueba que no tienen acceso a datos de producción.
4. Integración segura con cuentas de correo
Clauva permite conectar cuentas de correo compatibles con IMAP. El usuario configura la integración proporcionando credenciales que su proveedor habilita para este fin (por ejemplo, una contraseña de aplicación). Clauva no solicita ni almacena la contraseña principal de inicio de sesión de la cuenta de correo.
Las conexiones al servidor de correo del proveedor utilizan IMAP con cifrado en tránsito (TLS).
Almacenamiento y ciclo de vida de credenciales:
- las credenciales IMAP necesarias para el servicio se almacenan cifradas (AES-256-GCM) antes de persistirse en base de datos
- al desconectar la integración desde la plataforma, se eliminan las credenciales almacenadas en nuestros sistemas y se detienen las sincronizaciones asociadas
El tratamiento de datos obtenidos del correo se describe en nuestra Política de privacidad y en los Términos de Servicio.
5. Protección de datos del correo
Clauva accede al buzón mediante IMAP con criterios de búsqueda y procesamiento restrictivos como por ejemplo, ventanas de fechas coherentes con la sincronización, mensajes cuyo asunto coincide con palabras clave relacionadas con Documentos Tributarios Electrónicos o facturación electrónica definidas por Clauva y mensajes que incluyen adjuntos JSON identificables como candidatos a DTE. Más detalle en nuestra Política de privacidad.
De cada correo procesado almacenamos metadatos técnicos necesarios para la operación (por ejemplo, identificador del mensaje en el buzón y fecha/hora asociada al mensaje), según lo descrito en nuestra Política de privacidad. No almacenamos el cuerpo del correo con fines de archivo permanente para lectura humana generalizada; el tratamiento se centra en adjuntos y datos fiscales necesarios para el servicio.
La sincronización automática solo opera donde el usuario ha dado consentimiento explícito. El acceso automático programado ocurre en intervalos de tiempo predefinidos entre las 7:00 a.m. y las 7:00 p.m. hora de El Salvador (CST); fuera de ese horario no se realizan esos accesos automáticos al correo conectado.
6. Infraestructura y almacenamiento de datos
Clauva utiliza proveedores de infraestructura reconocidos:
| Componente | Proveedor / tecnología |
|---|---|
| Frontend | Vercel |
| Backend | NestJS en Railway |
| Base de datos | PostgreSQL (Railway) |
| Archivos (JSON/PDF de DTE) | Cloudflare R2 |
La base de datos PostgreSQL en Railway utiliza cifrado en reposo a nivel de infraestructura en los volúmenes. Las conexiones a la base de datos usan SSL/TLS de forma obligatoria.
Los archivos PDF/JSON de los Documentos Tributarios Electrónicos (DTE) en Cloudflare R2 se almacenan con cifrado en reposo. El acceso desde el cliente se realiza mediante URLs firmadas generadas por el backend, con duración limitada (por ejemplo, hasta 60 minutos). No ofrecemos URLs públicas permanentes a archivos privados.
7. Monitoreo y registros operativos
Registramos errores y señales de la infraestructura en las herramientas de observabilidad y despliegue del proveedor de hosting (por ejemplo, logs de deploy, builds, trazas HTTP del runtime y mensajes de error de la plataforma). Cuando aplica, el backend también emite registros de aplicación (por ejemplo, errores al procesar solicitudes), con acceso restringido al personal autorizado y retención limitada conforme a necesidades operativas.
Esos registros se gestionan con minimización de datos: no se incluyen credenciales IMAP (incluidas contraseñas de aplicación) ni contenido de correos en texto claro; evitamos registrar información sensible más allá de lo necesario para operar y depurar el servicio.
8. Acceso interno a datos
El acceso a datos de usuarios por parte del equipo de Clauva está restringido al personal autorizado y, en condiciones normales, se limita a lo necesario para soporte iniciado por el usuario, seguridad del servicio o cumplimiento legal.
Las cuentas administrativas en Railway, Vercel y Cloudflare utilizan autenticación de dos factores (2FA).
9. Revocación y control del usuario
Los usuarios pueden desconectar la integración de correo desde la plataforma (por ejemplo, en Integraciones) en cualquier momento. Al hacerlo, Clauva elimina las credenciales almacenadas y detiene las sincronizaciones asociadas, de acuerdo con nuestras políticas.
Quien lo desee puede además revocar o eliminar la contraseña de aplicación (o credencial equivalente) en la configuración de seguridad de su proveedor de correo, para impedir el acceso al buzón con esa credencial desde cualquier aplicación.
10. Eliminación de datos
Los usuarios pueden solicitar la eliminación de su cuenta y datos asociados. Al eliminar una cuenta, los datos pueden pasar a estado desactivado por un período (por ejemplo, hasta 30 días) para recuperación ante errores y, a continuación, eliminarse de forma definitiva de base de datos y almacenamiento en R2, salvo que su conservación sea necesaria para continuidad contable/operativa o por obligación legal aplicable.
Para más detalles: Eliminación de datos, la Política de privacidad y los Términos de Servicio.
11. Respuesta a incidentes
Contamos con un proceso interno para identificación, contención, análisis y remediación de incidentes de seguridad.
En caso de un incidente que afecte datos personales de usuarios, nos comprometemos a notificar a los afectados por correo electrónico en un plazo máximo de 72 horas desde la confirmación del incidente, describiendo la naturaleza del problema y las medidas tomadas, salvo restricciones legales o instrucciones de autoridades competentes.
12. Reporte de vulnerabilidades
Si descubres una vulnerabilidad en Clauva, comunícala de forma responsable antes de divulgarla públicamente, para permitir su corrección coordinada.
Envía tu reporte a soporte@clauva.app con el asunto "Reporte de seguridad", incluyendo descripción del problema, pasos para reproducirlo e impacto potencial. Nos comprometemos a responder en un plazo máximo de 3 días hábiles y a mantenerte informado sobre el proceso de corrección cuando aplique.
13. Mejora continua
Clauva revisa y mejora de forma continua sus prácticas de seguridad. Esta página se actualizará cuando haya cambios relevantes en controles o en la arquitectura del servicio.
No afirmamos certificaciones externas (por ejemplo, SOC 2) ni auditorías de terceros que no estén vigentes; si en el futuro se obtienen, se reflejarán aquí.