El precio founding está abierto: Pro al precio de hoy, bloqueado mientras te quedes. Plazas limitadas. Ver la oferta
Seguridad
Esta página describe las medidas a las que remite el contrato de encargo de tratamiento. Está escrita para ser verificable: cada medida nombra qué la aplica, para que una revisión de seguridad pueda comprobar en lugar de creer.
Cifrado
Todo el tráfico se sirve sobre TLS. Los tokens OAuth de terceros (Shopify, Google, Meta, Klaviyo, Notion, Figma) se cifran en reposo con AES-256-GCM bajo una clave que admite rotación, de modo que un volcado de base de datos no entrega credenciales utilizables. Los informes de verificación de identidad se cifran con el mismo esquema y nunca se muestran en el producto.
Aislamiento de inquilinos
Toda consulta que alcanza datos de organización o de tienda se acota por pertenencia, y ese acotado está cubierto por pruebas que hacen fallar la compilación en lugar de depender de la disciplina de revisión. Los roles son owner, admin, member y viewer, y los permisos se comprueban en el servidor en cada petición, nunca en el cliente.
Autenticación
El inicio de sesión usa un código de un solo uso de seis dígitos enviado por correo. No hay contraseña que filtrar ni enlace mágico que reenviar. Las sesiones viajan en una cookie con el prefijo __Secure-, caducan a los 30 días y bajan a 24 horas cuando inicias sesión sin pedir que te recuerden.
Registro de auditoría
Los eventos de seguridad y facturación se escriben en un registro de solo adición, visible en la actividad de tu cuenta. Las acciones administrativas de la plataforma se registran aparte. Las cargas útiles brutas de los webhooks se purgan con un calendario más corto que los propios eventos: el registro sobrevive, las cargas útiles no.
Secretos
Ninguna credencial está en el repositorio. El panel de operador que informa de la configuración de entorno expone solo 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 base de datos se derivan automáticamente y se aplican de forma idempotente, con una guarda que rechaza cualquier cambio capaz de fallar en producción en cuanto una tabla tiene filas. Un hook de pre-push ejecuta guardas offline rápidas (esquema, claims de documentación, copy, versiones) antes de que un cambio llegue al remoto. Lint, typecheck y la batería completa de pruebas corren en CI en cada pull request. La documentación que lees está a su vez protegida: las cifras publicadas se comparan con el código que las implementa.
Infraestructura
La plataforma funciona en Vercel con una base PostgreSQL gestionada en Neon, que aporta copias continuas y restauración a un instante concreto. Caché y colas funcionan en Upstash. Los pagos nunca tocan nuestros servidores: los datos de tarjeta los trata Stripe. La región de cada proveedor está publicada en la página de subencargados.
Supervisión
La plataforma publica una página de estado en vivo con 90 días de historial y un boletín mensual de disponibilidad. Los incidentes se declaran allí, con canal RSS y suscripción por correo. Los fallos a nivel de plataforma (registros, pagos fallidos) se resumen al operador cada hora.
Comunicar una vulnerabilidad
Escribe a contact@boostecom.app con detalle suficiente para reproducirla. Acusamos recibo en 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. Por favor, no hagas pruebas sobre la cuenta o la tienda de otro usuario.
Última actualización 12 de septiembre de 2026