Cómo protege Idovio Commerce las cuentas, los espacios de trabajo y las credenciales de las tiendas y los servicios que conecta el comerciante. Cada línea describe un control que forma parte del servicio; cuando algo no está terminado, se dice.
Las contraseñas se guardan únicamente como hashes scrypt con sal. Una contraseña debe tener al menos 12 caracteres con mayúsculas, minúsculas, un dígito y un carácter especial, no puede contener el nombre ni el correo de la persona y no puede ser una contraseña común.
Verificación en dos pasos con una aplicación de autenticación (TOTP) y códigos de recuperación de un solo uso. Es obligatoria para propietarios, administradores y cualquiera que conecte una tienda o cambie el equipo.
Las sesiones son tokens aleatorios opacos guardados como hash; en el navegador viajan en una cookie HttpOnly y Secure con protección SameSite y un segundo token contra la falsificación de peticiones entre sitios. Una sesión termina a los 30 días sin uso y como máximo a los 180 días de iniciarse. Cada dispositivo puede cerrarse desde la cuenta.
Los intentos de acceso están limitados por red y por cuenta, y los errores no revelan si una dirección está registrada.
Cada registro pertenece a un espacio de trabajo. El espacio se toma de la sesión, nunca de la petición; la pertenencia se comprueba en cada petición; y la propia base de datos impone la separación con seguridad a nivel de fila en todas las tablas con datos de espacios de trabajo, de modo que un error en el código de la aplicación no puede devolver filas de otro espacio.
Los roles deciden qué puede hacer cada miembro (propietario, administrador, operaciones, gestor de catálogo, gestor de pedidos, soporte, finanzas, analista, lector). El número de miembros y de conexiones lo limita el plan y lo impone el servidor.
Los tokens de acceso y las claves de API se cifran con AES-256-GCM bajo una clave propia del espacio de trabajo, protegida a su vez por una clave maestra que se guarda fuera de la base de datos (cifrado en sobre). El cifrado está ligado al espacio de trabajo y al nombre de la credencial, así que un texto cifrado movido a otro lugar no se descifra.
Una credencial guardada se puede sustituir o eliminar, pero nunca volver a leer: ni desde el navegador ni por la persona que la introdujo. En la web, las peticiones a un proveedor las hace el servidor, que añade allí la credencial; el primer uso liga la credencial a las direcciones de ese proveedor y se rechaza para cualquier otra.
Las conexiones piden a cada plataforma solo los permisos que las funciones necesitan. Desconectar elimina la credencial.
Todo el tráfico usa TLS; el HTTP sin cifrar se redirige y se indica a los navegadores que usen solo HTTPS (HSTS). La base de datos y el almacenamiento de archivos están cifrados en reposo por sus proveedores. La base de datos está en Fráncfort (Alemania).
Las consultas a la base de datos son parametrizadas. Los cuerpos de las peticiones se validan contra esquemas estrictos y los campos desconocidos se rechazan. Las respuestas llevan una política de seguridad de contenido restrictiva, no-sniff, prohibición de marcos y una política de referente estricta. El tamaño de las peticiones está limitado.
El inicio de sesión a través de un proveedor de identidad usa estado de un solo uso, nonce y PKCE, y solo vuelve a direcciones del servicio. Los webhooks de las plataformas de pago y de comercio se aceptan únicamente con una firma válida dentro de una ventana de tiempo corta, y cada evento se procesa una sola vez.
La automatización se ejecuta dentro de los límites que fija el comerciante (margen mínimo, pedido máximo, cambio máximo de precio, permisos por acción), puede exigir aprobación y puede detenerse en el acto.
Se lleva un registro de las acciones relevantes para la seguridad por espacio de trabajo, visible para su propietario: inicios de sesión, cambios de rol, invitaciones, conexiones y cambios de claves. Los registros del servicio llevan un identificador de petición y sustituyen contraseñas, tokens, cookies y claves antes de escribirse. Las direcciones de red se guardan abreviadas. No hay seguimiento publicitario ni de comportamiento.
La aplicación web es siempre la versión vigente. El servicio anuncia la versión más antigua de las aplicaciones de escritorio y móvil con la que sigue sincronizando; a una aplicación más antigua se le pide que se actualice y conserva sus datos en el dispositivo.
Existe un procedimiento escrito de respuesta a incidentes: identificar, contener (revocando sesiones y credenciales), preservar las pruebas, corregir, recuperar y notificar. Si un incidente afecta a datos personales, se informa sin dilación indebida a los clientes afectados, y a las plataformas y autoridades cuyas normas lo exijan. Comunica un posible incidente a security@idovio.com.
Escribe a security@idovio.com con lo que has encontrado y cómo reproducirlo. Confirmamos la recepción en dos días hábiles, te mantenemos informado y no emprendemos acciones legales contra la investigación hecha de buena fe que evite dañar los datos de otras personas y el servicio. Te pedimos un plazo razonable para corregir un problema antes de hacerlo público. La misma información está publicada en /.well-known/security.txt.
No se ha completado ninguna auditoría de seguridad independiente ni prueba de penetración del servicio, e Idovio Labs Ltd no dispone de ninguna certificación de seguridad (como ISO 27001 o SOC 2). La eliminación de los datos procedentes de proveedores se hace a petición; todavía no hay una purga automática por antigüedad para todos los tipos de registro. Esta página lo dirá cuando eso cambie.
