Seguridad

Autenticación

• Las contraseñas se cifran con scrypt y una sal por usuario.
• El inicio de sesión compara contra un hash ficticio cuando la dirección es desconocida, de modo que un intento fallido tarda lo mismo exista o no la cuenta.
• Las sesiones son tokens aleatorios opacos en una cookie httpOnly con SameSite=Lax (Secure en producción). En el servidor solo se guarda un hash SHA-256.
• Cambiar o restablecer una contraseña revoca todas las sesiones en todos los dispositivos.
• Los tokens de verificación y de restablecimiento son de un solo uso, se guardan cifrados y caducan (24 horas y 1 hora respectivamente).
• El inicio de sesión con Google verifica un parámetro de estado CSRF y se niega a vincular una dirección de Google no verificada con una cuenta existente.

Autorización

• Control de acceso basado en roles con una tabla de permisos, no comparaciones de rol dispersas. Roles: USER, AGENT_BUILDER, SUPPORT, MANAGER, ADMIN, SUPER_ADMIN.
• Toda consulta que lee datos de cliente está acotada por el identificador de usuario, de modo que un identificador de otra cuenta acaba en un 404 y no en una fuga.
• Las rutas de administración comprueban el permiso concreto que necesitan, con independencia del layout que dibuja la página.
• Nadie puede cambiar su propio rol o estado, ni conceder un rol por encima del suyo.

Protección de las peticiones

• CSRF: las mutaciones autenticadas por cookie exigen coincidencia de Origin y un token de doble envío.
• Limitación de frecuencia en inicio de sesión, registro, restablecimiento de contraseña, ejecuciones de agentes, formularios públicos y webhooks.
• Validación de entrada con Zod en cada frontera de la API. La entrada inválida devuelve errores por campo, nunca una traza de pila.
• El acceso a la base de datos pasa por Prisma con consultas parametrizadas; no hay SQL construido con cadenas.
• Las peticiones salientes de agentes y nodos de flujo rechazan las direcciones de bucle local y los rangos de red privados, bloqueando el SSRF.

Secretos

• Las credenciales de integraciones y los tokens OAuth se cifran con AES-256-GCM antes de almacenarse y nunca se envían a un navegador.
• Las claves de API se guardan como hashes SHA-256. La clave en bruto aparece exactamente una vez, en la respuesta de creación.
• Las claves de API de los proveedores viven solo en variables de entorno del servidor. Todas las llamadas a modelos ocurren en el servidor.
• Los registros pasan por un filtro de redacción que elimina los campos con forma de credencial.

Ejecución de agentes

• Las herramientas declaran un nivel de riesgo: READ, WRITE o DESTRUCTIVE. Cada versión de un agente declara el nivel máximo que puede ejecutar automáticamente.
• Una llamada por encima de ese techo se rechaza, se registra a la espera de aprobación y se comunica al modelo como no realizada.
• Las ejecuciones están acotadas por número de pasos, presupuesto de tokens y un tiempo límite.
• Cada paso se guarda con su entrada, su salida, su duración y su nivel de riesgo.

Pagos

• PROMIVO nunca ve ni guarda datos de tarjeta. Nuestro proveedor de pagos se ocupa de ello de principio a fin.
• Las firmas de los webhooks se verifican antes de leer la carga como datos.
• Cada evento se guarda bajo una restricción de unicidad, de modo que una reentrega se reconoce y se omite en vez de aplicarse dos veces.
• Los derechos de acceso los concede únicamente el manejador de webhooks, nunca una redirección de éxito del lado del cliente.

Informar de una vulnerabilidad

Contacto con los pasos para reproducirla. Danos un plazo razonable para corregir el problema antes de divulgarlo públicamente.