Nos pide componentes técnicos con datos de la empresa, acuerdos de precios y facturas. En esta página le explicamos exactamente cómo se protegen esos datos, desde la conexión en su navegador hasta los derechos de una sola línea de base de datos.
Última actualización: 20-08-2026
Conexión
TLS 1.2+ con HSTS, todo a través de HTTPS
Datos de tarjeta
Nunca en nuestras manos, gestionado por Stripe
Acceso a la base de datos
Seguridad a nivel de fila en cada tabla
Cuentas
Contraseñas hasheadas y 2FA disponible
01
Principios
La seguridad de esta tienda online se basa en tres principios: los datos se cifran en tránsito y en reposo, cada usuario solo ve lo que corresponde a su propia cuenta de empresa, y las decisiones sobre dinero y derechos siempre se toman en el servidor, nunca en el navegador.
Esto último es más importante de lo que parece: todo lo que se ejecuta en su navegador puede ser modificado por un visitante. Por eso, el servidor comprueba de nuevo los precios, los descuentos por volumen, el tratamiento del IVA y los derechos en cada pedido, independientemente de lo que envíe la página web.
Derechos mínimos: cada componente solo obtiene el acceso que realmente necesita.
Defensa en capas: si una medida falla, hay otras entre un atacante y sus datos.
Minimización de datos: no almacenamos datos que no necesitamos para procesar su pedido.
Auditabilidad: las acciones sensibles dejan rastros en los archivos de registro.
02
Conexión cifrada y encabezados de seguridad
Todo el tráfico entre su navegador y la tienda online se realiza a través de HTTPS con TLS 1.2 o superior. Las solicitudes a través de HTTP se redirigen automáticamente a HTTPS y el sitio envía un encabezado HSTS, para que su navegador se niegue a conectarse sin cifrar en el futuro.
Además, el servidor envía un conjunto de encabezados de seguridad que reducen el margen de maniobra de un posible ataque.
Content-Security-Policy: determina qué scripts, estilos, imágenes y conexiones están permitidos, evitando que el código inyectado se ejecute o redirija sin más.
X-Content-Type-Options: nosniff — el navegador no debe reinterpretar los tipos de archivo por sí mismo.
X-Frame-Options / frame-ancestors: la tienda online no se puede cargar en un marco de otro sitio (clickjacking).
Referrer-Policy: al salir del sitio, no se proporciona una URL completa con parámetros.
Permissions-Policy: la cámara, el micrófono y la ubicación están bloqueados; la tienda online no los necesita.
03
Cuentas e inicio de sesión
Las cuentas se ejecutan en una plataforma de autenticación gestionada. Las contraseñas nunca se almacenan de forma legible: se almacenan con una función hash moderna y salada y no podemos verlas ni descifrarlas. No hay auto-registro anónimo con derechos elevados; las nuevas cuentas de empresa se vinculan a una empresa.
Después de iniciar sesión, recibe un token de acceso de corta duración más un token de actualización. El token de acceso expira automáticamente, de modo que un token filtrado solo es utilizable por un corto período. Cerrar sesión revoca la sesión.
La autenticación de dos factores (2FA) a través de una aplicación de autenticación se puede activar por usuario.
Las direcciones de correo electrónico se verifican antes de que una cuenta esté completamente activa.
La recuperación de contraseña se realiza a través de un enlace de un solo uso con corta validez.
Los intentos de inicio de sesión están limitados, para que las contraseñas no puedan adivinarse sistemáticamente.
También puede iniciar sesión de forma segura durante el proceso de pago; su carrito de compras se mantendrá.
04
Cuentas de empresa, roles y separación de datos
Una cuenta de empresa puede contener varios empleados. Cada empleado tiene un rol que determina lo que puede hacer: realizar pedidos, solo ver o administrar la cuenta. Los roles se almacenan en una tabla separada, no en el perfil del usuario, precisamente para evitar que alguien pueda ascender a administrador a través de una edición de perfil.
Los controles de rol siempre se realizan en la base de datos con funciones auxiliares fijas de solo lectura. El navegador puede saber lo que debe mostrar, pero nunca determina lo que puede hacer.
Comprador: puede realizar pedidos dentro del límite de crédito acordado y completar las referencias de PO.
Visor: puede ver pedidos y facturas, pero no realizar pedidos.
Administrador: puede añadir empleados, ajustar derechos y gestionar datos de la empresa.
Los empleados de la empresa A no pueden solicitar técnicamente los pedidos, facturas y precios de la empresa B.
05
Seguridad de la base de datos: seguridad a nivel de fila
La base de datos no está abierta. En cada tabla con datos de clientes, la seguridad a nivel de fila (RLS) está activada, con reglas explícitas que determinan por fila quién puede leerla, crearla, modificarla o eliminarla. Sin una regla adecuada, una fila es simplemente invisible, incluso con una consulta mal escrita en la aplicación.
Además, los derechos estándar sobre el esquema de la base de datos se han revocado y solo se han concedido de forma específica. Los datos públicos, como textos de productos, dimensiones y categorías, son deliberadamente legibles; todo lo que está vinculado a un cliente no lo es.
Pedidos, presupuestos, facturas y direcciones están vinculados a la empresa del usuario que ha iniciado sesión.
Los mensajes de los formularios de contacto y presupuesto pueden crearse, pero no pueden leerse públicamente.
Las funciones de administración están protegidas con un control de roles separado y no son accesibles para cuentas normales.
Las funciones de base de datos con derechos elevados tienen una ruta de búsqueda fija y no son ejecutables para visitantes no registrados.
06
Pagos
Los pagos se realizan a través de Stripe, un proveedor de servicios de pago certificado por PCI-DSS. Los datos de su tarjeta o iDEAL se introducen en un entorno de Stripe y nunca pasan por nuestros servidores ni por nuestra base de datos. Solo recibimos el estado del pago y una referencia de transacción.
El importe que usted paga se calcula en el servidor: los precios de los artículos, los descuentos por volumen, los gastos de envío y el IVA se vuelven a calcular a partir de la base de datos. Por lo tanto, un carrito de compras manipulado o un precio ajustado en el navegador no conduce a un pedido más barato.
La retroalimentación de Stripe llega a través de un webhook cuya firma se verifica criptográficamente.
Los webhooks son idempotentes: una notificación recibida dos veces no conduce a un pedido doble o a un procesamiento doble.
Un pedido solo se marca como pagado después de la confirmación de Stripe, no después de regresar al navegador.
El tratamiento del IVA (incluido el traslado dentro de la UE) se determina en el lado del servidor, con validación del número de IVA a través de VIES.
07
Protección contra el abuso y la sobrecarga
Los formularios y los puntos finales sensibles están provistos de limitación de velocidad: el número de intentos por visitante dentro de un período de tiempo está limitado. Esto frena el envío automatizado de spam, la exploración de cuentas y el agotamiento de nuestra capacidad de correo electrónico.
El contador para esta limitación está protegido de tal manera que los usuarios no pueden invocarlo o influenciarlo por sí mismos; solo el servidor lo actualiza.
Los formularios de presupuesto, contacto y registro están limitados por dirección IP y por cuenta.
Toda la entrada se valida en el lado del servidor por tipo, longitud y formato antes de que se almacene algo.
Las cargas de archivos están limitadas en tipo y tamaño y se almacenan fuera del entorno de la aplicación.
Los parámetros de búsqueda y filtro se analizan y controlan, nunca se pegan directamente en una consulta.
08
Desarrollo seguro
La tienda online está construida con una aplicación moderna renderizada en el lado del servidor en la que el acceso a la base de datos se realiza exclusivamente a través de funciones tipadas del servidor. Las consultas están parametrizadas, lo que elimina los puntos de entrada para la inyección SQL, y la salida se escapa por defecto por el framework, lo que contrarresta el cross-site scripting.
Los secretos, como las claves API, nunca están en el código fuente o en el paquete del navegador. Se leen como variables de entorno seguras en el momento en que se ejecuta una función del servidor.
El código del cliente y del servidor están estrictamente separados; los módulos solo de servidor no pueden terminar en el paquete del navegador.
Las dependencias se escanean periódicamente en busca de vulnerabilidades conocidas y se actualizan.
Los cambios se prueban primero en un entorno de previsualización antes de que se publiquen.
La base de datos se audita regularmente con un linter de seguridad en busca de reglas faltantes y derechos demasiado permisivos.
09
Alojamiento, copias de seguridad y continuidad
La aplicación se ejecuta en una infraestructura gestionada con renovación automática de certificados, mitigación de DDoS a nivel de red y una red de borde distribuida globalmente. La base de datos se encuentra en un centro de datos dentro de la Unión Europea y el almacenamiento está cifrado en reposo.
Se realizan copias de seguridad diarias con posibilidad de restauración a un momento anterior. Los procedimientos de recuperación se prueban periódicamente, para que una acción de restauración no sea una improvisación.
Cifrado en reposo a nivel de base de datos y almacenamiento de objetos.
Copias de seguridad diarias con período de retención y recuperación a un momento determinado.
El acceso de administrador a la infraestructura está limitado a unas pocas personas y protegido con 2FA.
Los controles de estado y los mensajes de error se monitorean, para que las interrupciones se detecten rápidamente.
10
Registro, monitoreo y fugas de datos
Los eventos importantes (intentos de inicio de sesión, cambios de estado de pedidos, acciones administrativas y errores en el servidor) se registran. Los archivos de registro no contienen contraseñas ni datos de pago y se conservan durante un máximo de doce meses.
En caso de sospecha de una fuga de datos, investigamos inmediatamente el alcance, cerramos la fuga e informamos a las partes afectadas y, cuando el GDPR lo exige, a la Autoridad de Protección de Datos en un plazo de 72 horas.
11
Lo que usted mismo puede hacer
La seguridad es una responsabilidad compartida. La mayoría de los incidentes en las tiendas online no comienzan en el sitio web, sino con una contraseña reutilizada o un correo electrónico de phishing convincente.
Utilice una contraseña única y larga y guárdela en un gestor de contraseñas.
Active la autenticación de dos factores para todos los usuarios de su cuenta de empresa.
Elimine inmediatamente de la cuenta a los empleados que dejen la empresa.
Nunca le pediremos su contraseña o código 2FA por correo electrónico o teléfono.
Si el número de cuenta bancaria de una factura ha cambiado, compruébelo siempre telefónicamente con nosotros a través del número que aparece en este sitio.
12
Notificación responsable de vulnerabilidades
¿Descubre una debilidad? Infórmenos antes de hacerla pública. Envíenos un correo electrónico con una descripción, la URL afectada y los pasos para reproducirla. Confirmaremos la recepción, le mantendremos informado y, si lo desea, le mencionaremos por su nombre una vez que se resuelva el problema.
Le pedimos que: no utilice ataques automatizados que interrumpan el servicio, no acceda a datos de otros clientes, y no modifique ni elimine nada.
¿Ha encontrado una vulnerabilidad o tiene alguna pregunta sobre seguridad?
Infórmenos por correo electrónico con una descripción y los pasos para reproducirla. Normalmente respondemos en dos días hábiles y le mantenemos informado hasta que se resuelva. Por favor, nunca pruebe con datos reales de clientes y no realice ataques que interrumpan el servicio.