Encryption & key handling

Encryption in transit and at rest

All traffic between your device and Aiemaily’s servers travels over TLS 1.2+ with modern cipher suites. Connections that fall back to older TLS versions are rejected at the load balancer.

Data at rest — message bodies, metadata, summaries — is encrypted using AES-256 at the storage layer. Object storage blobs (message bodies) carry an additional per-object encryption key managed by a KMS, so a compromised storage layer cannot yield plaintext without also compromising the KMS.

Least-privilege everywhere

Aiemaily requests the minimum OAuth scopes needed for each mail provider. For Gmail this means read + send + label management; we never request contacts export, Drive access, or admin APIs. Scope grants are surfaced in the connection UI so you can see exactly what you’ve authorised.

Every database row, object storage blob, and function invocation carries an owner ID. Requests that don’t present a matching JWT are rejected at the data layer, not just the API layer. This object-level authorisation means a bug in the API routing cannot leak one user’s data to another.

Webhooks, CORS, and CSP

Inbound webhooks from Stripe, Gmail Push Notifications, and Microsoft Graph are validated with HMAC signatures before any payload is processed. Replayed or tampered webhooks are silently dropped and logged.

The web app ships with a strict Content Security Policy that blocks inline scripts, restricts fetch targets to our own domains and known API hosts, and disallows framing from third-party origins. CORS is configured per-route to allow only the production and staging origins.

Idempotency and safe retries

Every mutating API call — send, archive, label, delegate — accepts an idempotency key so that network retries can’t duplicate actions. This is especially important for send: if a connection drops after the server accepts the request, a retry with the same key is a no-op, not a duplicate send.