Security at Maildriply

• Least privilege. We request the narrowest Google scope that lets the product work: gmail.send plus the standard openid email profile for sign-in. We do not have permission to read your inbox, modify messages, or manage labels.
• Single tenant per user. All API requests are authenticated with a per-user Supabase JWT, and database queries are scoped to the requesting user's ID.
• Defense in depth. Sensitive data is encrypted at rest, tokens are signed and timing-safe-verified, and links from tracked emails cannot redirect anywhere except a URL we recorded at send time.

• Google refresh tokens are sealed with AES-256-GCM envelope encryption before being written to the database. The encryption key is a 32-byte secret held only in the running application's environment.
• We never store your Google password — sign-in is OAuth 2.0 with the standard Google consent screen.
• On disconnect or account deletion we call Google's oauth2.googleapis.com/revoke endpoint so the refresh token is invalidated server-side before our local row is removed.

• TLS 1.2+ everywhere. HSTS is enforced on the dashboard, marketing, API, and tracking hosts.
• CORS is restricted to known dashboard origins plus the Chrome extension origin. The marketing site never calls the API directly.
• Strict Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a restrictive Permissions-Policy are returned from the dashboard and marketing sites.
• Per-IP rate limits protect /api/*, OAuth consume, account deletion, and the public tracking endpoints.
• The app subdomain (app.maildriply.com) is isolated from the marketing apex with separate cookie scope. A leaked marketing XSS cannot read app session cookies, and vice-versa.

• Open, click, and unsubscribe URLs embed compact HMAC-SHA256 signed tokens that contain only opaque database IDs. Tokens are verified with a timing-safe comparison; forged tokens are rejected.
• Click redirects look up the destination URL by ID in our database; the URL is never trusted from the request, so the tracking endpoint cannot be turned into an open-redirect.
• Open events are classified to filter Gmail image-proxy prefetches and Apple Mail Privacy Protection so “unique opens” stays honest.

• Application logs redact authorization headers, refresh tokens, and encrypted-token fields before they are written.
• Production secrets live only in platform-managed environment variable stores (Heroku, Vercel, Supabase, Upstash). They are rotated when needed and never committed to the repository.
• Database backups are encrypted by Supabase and retained for the window the platform offers.
• We perform basic audit logging of OAuth, send, and account lifecycle events for incident response and abuse review.

• Compromise of your Google account. If someone else has signed-in access to your Google account, they can take actions in Maildriply. Enable 2-Step Verification on your Google account.
• Recipient-side behavior. An open event is a request from a recipient's mail client for the tracking pixel. We cannot guarantee a human actually viewed the message.

We take security reports seriously. If you discover a vulnerability, email support@maildriply.com with a description and reproduction steps. Please give us a reasonable window to remediate before disclosing publicly. We do not currently run a paid bug bounty.