Skip to content

Security documentation

This page documents implemented application controls. It is not an external audit, certification, penetration-test report, or uptime commitment.

Tenant access

Dashboard access resolves store membership and capability grants on the server. Widget, public API, MCP, journey, and recovery paths reject stores that are not active.

Secrets and identity

Store and connector secrets use AES-256-GCM encryption with context binding. Passwords use scrypt and timing-safe comparison. TOTP, backup codes, and session invalidation are available for dashboard accounts (detailed below).

Two-factor authentication

Dashboard accounts support optional two-factor authentication using standard TOTP (RFC 6238: 6-digit codes, 30-second period), compatible with Google Authenticator, Microsoft Authenticator, Authy, 1Password, and any other RFC-compliant authenticator app. Enroll at Dashboard → Settings → Security: scan the QR code, confirm a 6-digit code from the app, and save the 10 single-use backup codes. They are shown exactly once, at enrollment.

  • Sign-in is two-step: the code screen appears only after the password verifies, and only for 2FA-enabled accounts. The 2FA requirement is never revealed to someone who does not hold the password, which reduces disclosure through that flow. It does not establish that every account-enumeration path is eliminated.
  • TOTP secrets are stored AES-256-GCM encrypted at rest with per-user context binding; backup codes are stored only as hashes, never in plaintext.
  • Codes are single-use: a replay guard rejects a valid TOTP code presented a second time within its window, and each backup code is consumed on use.
  • Disabling 2FA requires a valid authenticator or backup code, so a session alone is insufficient to disable the protection through that flow. Protect authenticator recovery and backup codes separately.
  • “Sign out everywhere” on the same page invalidates every session for the account; tokens issued before that moment are rejected on their next request.

Ingress and egress

Shopify, Freemius, and legacy Stripe webhooks verify provider signatures. API bodies use schema validation. Email sending rejects control characters and reserved injected headers before transport.

Privacy and retention

Consent is scoped per store, optional tracking defaults off, GPC disables marketing tracking, shopper erasure covers linked tenant data, and scheduled retention removes data on configured windows.

Service availability

These docs do not promise multi-region failover or a verified recovery objective. Merchants should use the Privacy policy, support team, and their executed agreement for current availability and resilience commitments.

Missing something, or found an error on this page?

Contact support and include the URL of this page (/docs/security).