Security
This page describes the measures referenced by the Data Processing Agreement. It is written to be verifiable: each measure names what enforces it, so a prospect's security review can check rather than trust.
Encryption
All traffic is served over TLS. Third-party OAuth tokens (Shopify, Google, Meta, Klaviyo, Notion, Figma) are encrypted at rest with AES-256-GCM under a key that supports rotation, so a database dump does not yield working credentials. Identity verification reports are encrypted under the same scheme and are never rendered in the product.
Tenant isolation
Every query that reaches organisation or store data is scoped by membership, and that scoping is covered by tests that fail the build rather than by review discipline. Roles are owner, admin, member and viewer, and permissions are checked server-side on each request, never in the client.
Authentication
Sign-in uses a six-digit one-time code delivered by email. There is no password to leak and no magic link to forward. Sessions are carried in a cookie with the __Secure- prefix, expire after 30 days, and drop to 24 hours when you sign in without choosing to be remembered.
Audit logging
Security and billing events are written to an append-only log, visible to you under your account activity. Administrative actions taken by the platform are recorded separately. Raw webhook payloads are pruned on a shorter schedule than the events themselves, so the log survives while the payloads do not.
Secrets
No credential is committed to the repository. The operator dashboard that reports on environment configuration exposes only whether a key is set, never its value. A test rejects any value resembling a secret in the versioned MCP configuration file.
Integrity and change control
Database schema changes are derived automatically and applied idempotently, with a guard that refuses any change capable of failing in production once a table holds rows. A pre-push hook runs the full test suite before any change can reach the remote. The documentation you are reading is itself guarded: published figures are compared against the code that implements them.
Infrastructure
The platform runs on Vercel with a managed PostgreSQL database on Neon, which provides continuous backups and point-in-time restore. Caching and queues run on Upstash. Payments never touch our servers: card data is handled by Stripe. Each provider's region is published on the sub-processors page.
Monitoring
The platform publishes a live status page with 90 days of history and a monthly uptime report card. Incidents are declared there, with an RSS feed and an email subscription. Platform-level failures (signups, failed payments) are digested to the operator hourly.
Reporting a vulnerability
Write to contact@boostecom.app with enough detail to reproduce. We acknowledge within three business days. We will not pursue legal action over good-faith research that respects user privacy, avoids data destruction and does not degrade the service. Please do not test against another user's account or store.
Last updated September 12, 2026