Testlie
Menu

Trust

On this page

Security

Captured email, texts and requests are untrusted content that can contain anything, and the sandboxes hold credentials your apps use. This page describes how Testlie handles both. The public security page covers the hosted service and how to report a vulnerability.

Mail never leaves by accident

  • The SMTP server never relays. Mail is stored in the inbox that authenticated (or the inbox that owns the inbound alias) and is not sent on, whatever its recipients.
  • Forwarding needs consent. Captured mail only leaves through forwarding, and only to addresses that confirmed by clicking a link sent to them. A loop guard stops a message after three forwards. On the hosted service a forward is a new message with the original attached, so a captured From address is never relayed as if it were real.
  • Outgoing mail (forwarding, invitations, verification) goes only through Testlie's own email provider.

Untrusted HTML

  • Sandboxed previews. Message HTML is served from its own endpoint with a Content-Security-Policy that sandboxes the document and blocks scripts, objects and frames, and is shown in a sandboxed iframe. cid: images are inlined.
  • No access to your session. The sandbox gives the preview an opaque origin without scripts, allow-same-origin or forms, so a message cannot read the app's cookies or call its API, even though previews are served from the app's own domain. Request bin responses get the same treatment: a sandboxing CSP, nosniff, and no Set-Cookie, redirect or framing headers.
  • Image proxy. With IMAGE_PROXY on (the hosted default), remote images and stylesheets load through the app: senders' tracking pixels cannot see who opened a message or from where. Proxied URLs are signed, so the proxy cannot be used for arbitrary fetches.
  • Attachments always download (Content-Disposition: attachment, X-Content-Type-Options: nosniff); they are never rendered in the app's origin.

Outbound requests (SSRF)

Webhooks and the image proxy fetch URLs that users supply. Both refuse targets that resolve to private, loopback, link-local, multicast or reserved addresses (IPv4 and IPv6, including IPv4-mapped forms). The check runs inside the connection's own DNS lookup, so a hostname cannot pass the check and then re-resolve to an internal address. URLs with embedded credentials and non-HTTP schemes are rejected. WEBHOOK_ALLOW_PRIVATE=true lifts this for local development only.

Secrets

  • Encrypted at rest. Inbox SMTP and SMPP passwords, sandbox tokens, webhook signing secrets and SCIM tokens are stored encrypted with AES-256-GCM, because the app must be able to show or use them again.
  • Uploaded keys. When you upload an APNs .p8 key, only its public key is kept; the push sandbox needs nothing more to verify your tokens.
  • API keys are hashed. Keys are shown once and stored as SHA-256 hashes. They can be read-only and can expire.
  • 2FA secrets are encrypted by the authentication library; passwords are hashed with scrypt.
  • Webhook payloads are signed with HMAC-SHA256 over the timestamp and body.

Transport and headers

  • The web app and API are served over HTTPS only, with security headers on every response.
  • SMTP offers STARTTLS on its submission ports and implicit TLS on 465; SMPP is offered over TLS on port 3550.

Accounts and access

  • Every API request is scoped to one team: rows of another team answer 404, never 403, so IDs cannot be probed.
  • Roles (owner, admin, member) gate configuration; API keys cannot manage keys, members or SSO.
  • Sign-in supports two-factor authentication, team SSO (OIDC and SAML), and social providers. Sign-in, sign-up, password reset and verification emails are rate limited. The next parameter after sign-in only accepts same-site paths.
  • The SMTP server limits connections and failed logins per IP address, and messages per inbox per minute.
  • Mock identity providers can be protected so only signed-in team members (or CI with the access cookie) can use their login screen.

Audit log

Admins see a team audit log of inbox, project, API key, webhook, identity provider, forwarding-address and forwarding changes, emptied inboxes and forwarded messages, with who did it and when.

Retention

Messages are removed by the inbox's message limit, by the plan's retention period, and when disposable inboxes expire. Stored objects of deleted messages are purged by the worker, including from S3 buckets. Webhook delivery logs are kept for 30 days and IdP activity logs for 30 days.