Security measures

1. Access control

• Passwords are stored only as bcrypt hashes; at least 10 characters with a letter and a digit or special character are required.
• Sign-in attempts are rate-limited per IP address and per account; messages don’t reveal whether an account exists.
• Optional two-step verification (TOTP codes from an authenticator app, one-time backup codes stored as SHA-256 hashes, protection against code reuse) and sign-in with a passkey (WebAuthn), whose private key never leaves the user’s device.
• Sessions live in a signed cookie with the HttpOnly, Secure and SameSite flags; permissions are checked in the database on every request, so removing a role or suspending access takes effect immediately.
• Invitation and password reset links are single-use, random and short-lived (7 days / 1 hour); only their SHA-256 hashes are stored.
• API tokens are shown once, stored as SHA-256 hashes, act with their creator’s permissions and expire with the creator’s role; they cannot create further tokens or delete Organizations.
• A least-privilege role model: a Member sees only the assigned mailbox; Administrator permissions are granted individually; nobody can grant permissions higher than their own.

2. Isolation of Organization data

• Every database query is scoped to the caller’s Organization; other Organizations’ resources return a 404 error so their existence is not revealed.
• The database is reachable only from the application server with a service key; public database roles have no access to any table (Row Level Security).
• An Organization’s webhook can change only that Organization’s data; a domain verified in one Organization cannot be taken over by another.
• Addresses of deleted mailboxes on the service domain are held for 90 days before they can be assigned again.

3. Encryption

• Connections only over HTTPS (TLS 1.2+), with an HSTS header.
• Resend and AI provider API keys and webhook secrets are encrypted in the application with AES-256-GCM; they are never returned by the API or shown in the browser (only the last 4 characters are visible).
• Data in the database and backups is encrypted at rest by the infrastructure provider (AES-256).
• Mail from the saauf.xyz domain is DKIM-signed and protected by SPF and DMARC records; mail servers use TLS whenever the receiving side supports it.

4. Application security

• HTML message content is shown in an isolated sandboxed frame without scripts, under a strict CSP; remote images are blocked until the reader allows them.
• Security headers: framing disallowed, nosniff, referrer and browser permissions policies.
• Webhooks are verified with an HMAC signature (Svix) with a 5-minute time tolerance; the service’s receiver rejects all requests until a secret is configured.
• Server-side input validation, content size limits and abuse protection (rate limits, a honeypot field at sign-up).
• Dependencies are kept up to date and code changes are reviewed before deployment.

5. Accountability

• The Organization activity log records, among other things, changes to members and roles, mailboxes, domains, integrations and AI settings, exports and data deletion — who, what and when. It is kept for 24 months.
• The version and date of acceptance of the Terms of service and the data processing agreement are recorded.
• Service Provider staff need a separate role to access the service panel; actions in Organizations are recorded in their log.

6. Data minimization and lifecycle

• Mail to addresses that are not a mailbox of any Organization is not stored.
• The Organization sets the message retention period (30–730 days or no limit); older messages are deleted automatically every day.
• Deleting individual messages and threads, as well as all messages with a given address; export of all Organization and Account data.
• Automatic clean-up: attempt counters after 48 hours, expired links and invitations after 30 days, AI statistics after 13 months, the activity log after 24 months.
• Only the content needed for a reply is sent to the AI provider; AI usage statistics contain no message content. Content is not used to train models.

7. Availability and business continuity

• Database in the region: European Union (Frankfurt, eu-central-1), with daily backups at the infrastructure provider.
• The application runs in a serverless environment with automatic scaling; scheduled AI replies are held by the mail provider, so they are not lost when the application restarts.
• Receiving mail is idempotent: repeated deliveries of the same event do not create duplicates.

8. Organizational measures

• Access to production data only for authorized persons bound by confidentiality, to the extent necessary to maintain the service.
• Incident handling procedure: assessment, containment, notifying the Organization within 36 hours of discovering a breach, documentation.
• Assessment of providers before entrusting them with data, and a data processing agreement with each of them.
• Vulnerability and incident reports are accepted at security@saauf.xyz.

Reporting vulnerabilities

Found a security issue? Write to security@saauf.xyz. We’ll acknowledge your report within 3 business days and let you know when it’s resolved. Please don’t test on other Organizations’ data and don’t disclose the issue before it’s fixed. Contact details are also in security.txt.