Security

Credential protection

• Encryption at rest. OAuth refresh and access tokens are encrypted with AES-256-GCM, an authenticated cipher, so tampering with stored ciphertext is detected rather than silently decrypted. The key is supplied through the environment and is not stored in the database alongside the data it protects.
• Key rotation support. Stored ciphertext carries a version prefix, so a future key rotation can read old values while writing new ones without a migration.
• Tokens never reach the browser. All Gmail API calls are made server-side. No access token, refresh token, or client secret is ever sent to a client.
• No Google passwords. Authorization happens on Google’s domain. We never see a password and cannot bypass two-factor authentication.

Tenant isolation and authorization

• Row-level security. Isolation between organizations is enforced in the database, not only in application code. A query issued on behalf of one organization cannot return another’s mail even if application logic were wrong.
• Server-side re-verification. Every API route independently resolves and checks the caller’s session. The routing layer’s redirect is a convenience, never the security boundary.
• Object-level checks. Requests that name a thread, message, or attachment are checked against the caller’s organization before anything is returned, so an identifier guessed or copied from elsewhere is rejected.

OAuth flow hardening

• State tokens are generated server-side, single-use, bound to the requesting member, and expire in ten minutes. A replayed or expired callback is rejected.
• The mailbox identity is taken from Google’s token response, never from a value supplied by the browser, so a crafted request cannot bind someone else’s tokens to an account.
• If Google returns a partial grant missing a scope the product needs, the connection is rejected rather than left half-working.
• Post-sign-in redirects are restricted to same-origin paths, so a crafted link cannot bounce a freshly signed-in member to another site.

Handling message content safely

• HTML sanitization. Mail is sanitized before rendering against an allowlist of elements and attributes, so a malicious message cannot execute scripts in the application.
• Attachments are not stored. Bytes are fetched from Gmail on demand and streamed to the member who requested them, which removes a whole category of risk around stored file contents.
• Logging discipline. Operational logs identify accounts and operations by identifier. They are not a place where message bodies are written.

Transport and infrastructure

• All traffic is served over HTTPS, and connections to Google and to our database use TLS.
• Webhook endpoints that receive Gmail change notifications verify the caller before acting, so they cannot be driven by an arbitrary request.
• Secrets are supplied through environment configuration and validated at startup, so a misconfigured deployment fails loudly rather than running in a degraded state.
• Infrastructure providers are listed on the subprocessors page.

Personnel access

Administrative access to production systems is limited to the personnel who need it to operate the service. Staff do not read members’ mail as a matter of course; the narrow exceptions are set out in the privacy policy. Connecting and disconnecting a mailbox is recorded in an audit log.

Independent assessment

Because we request the restricted scope gmail.modify and retain data obtained under it, this application falls within the scope of Google’s restricted-scope requirements, which include an annual independent security assessment. We have built the application with those requirements in mind and will complete the assessment as part of verification. We will not describe ourselves as having passed it until we have.

Reporting a vulnerability

If you believe you have found a security issue, email security@uniebox.vercel.app. Please include enough detail to reproduce the issue. We aim to acknowledge reports within two business days.

We ask that you give us a reasonable opportunity to fix an issue before disclosing it publicly, and that you avoid accessing, modifying, or deleting data that is not your own while investigating.

Incident response

If a breach affects personal data, we will investigate, contain it, and notify affected members and any applicable regulator within the timeframes the law requires.