Esta página describe las medidas a las que remite el contrato de encargo del tratamiento. Está redactada para poder verificarse: cada medida indica qué la aplica, de modo que la auditoría de seguridad de un cliente potencial pueda comprobar en lugar de fiarse.

Cifrado

Todo el tráfico circula por TLS. Los tokens OAuth de terceros (Shopify, Google, Meta, Klaviyo, Notion, Figma) se cifran en reposo con AES-256-GCM mediante una clave que admite rotación, de modo que una copia de la base de datos no proporciona ninguna credencial utilizable. Los informes de verificación de identidad se cifran con el mismo método y nunca se muestran en el producto.

Aislamiento de los datos de cada cliente

Toda consulta que accede a datos de una organización o de una tienda se filtra según la pertenencia a la organización, y ese filtrado está cubierto por pruebas que hacen fallar la compilación, no solo por el rigor de las revisiones. Los roles son propietario, admin, miembro y observador, y los permisos se comprueban en el servidor en cada petición, nunca en el cliente.

Autenticación

El inicio de sesión se hace con un código de un solo uso de seis dígitos enviado por email. No hay ninguna contraseña que pueda filtrarse ni ningún enlace mágico que reenviar. Las sesiones van en una cookie con el prefijo __Secure-, caducan a los 30 días y se reducen a 24 horas cuando inicias sesión sin pedir que se recuerde el dispositivo.

Registro de auditoría

Los eventos de seguridad y facturación se escriben en un registro inalterable (solo admite nuevas entradas), que puedes consultar en la actividad de tu cuenta. Las acciones administrativas de la plataforma se registran aparte. El contenido bruto de los webhooks se purga antes que los propios eventos: el registro se conserva, el contenido bruto no.

Secretos

Ninguna credencial se guarda en el repositorio. El panel de operador que informa sobre la configuración del entorno solo indica si una clave está definida, nunca su valor. Una prueba rechaza cualquier valor que parezca un secreto en el archivo de configuración MCP versionado.

Integridad y control de cambios

Los cambios del esquema de la base de datos se derivan automáticamente y se aplican de forma idempotente, con una salvaguarda que rechaza cualquier cambio que pueda fallar en producción en cuanto una tabla contiene filas. Antes de que un cambio llegue al repositorio remoto, un hook de pre-push ejecuta comprobaciones rápidas sin conexión (esquema, afirmaciones de la documentación, textos, versiones). El lint, la comprobación de tipos y la batería completa de pruebas se ejecutan en integración continua en cada pull request. La documentación que estás leyendo también está bajo control: las cifras publicadas se comparan con el código que las implementa.

Infraestructura

La plataforma funciona en Vercel, con una base de datos PostgreSQL gestionada en Neon, que ofrece copias de seguridad continuas y restauración a un momento concreto. La caché y las colas funcionan en Upstash. Los pagos nunca pasan por nuestros servidores: los datos de tarjeta los trata Stripe. La ubicación de cada proveedor está publicada en la página de subencargados.

Supervisión

La plataforma publica una página de estado en tiempo real con 90 días de historial y un informe mensual de disponibilidad. Los incidentes se declaran allí, con un canal RSS y una suscripción por email. Los fallos a nivel de plataforma (registros, pagos fallidos) se envían al operador en un resumen cada hora.

Comunicar una vulnerabilidad

Escribe a contact@boostecom.app con detalles suficientes para reproducir el problema. Acusamos recibo en un plazo de tres días hábiles. No emprenderemos acciones legales contra una investigación de buena fe que respete la privacidad de los usuarios, evite destruir datos y no degrade el servicio. Te pedimos que no hagas pruebas sobre la cuenta o la tienda de otro usuario.

Última actualización 12 de septiembre de 2026