Testlie

Security

Testlie holds two sensitive things: what your applications send to it (email, text and WhatsApp messages, push notifications, calls and HTTP requests), which can contain anything, and the credentials your apps use to reach it. This page describes how we protect both. For technical detail, see the security documentation.

Captured messages never reach real recipients

Every sandbox is a simulation: texts, WhatsApp messages, push notifications and calls are captured and never sent to a carrier, Apple, Google, Meta or a real phone. The SMTP server stores every message in the inbox that authenticated and never relays it. The only way an email leaves is forwarding, and forwarding only goes to addresses that have confirmed, by clicking a link sent to them, that they want it. On the hosted service, forwards are sent as a new message with the original attached, so a captured sender address is never passed on as if it were real, and a loop guard stops mail that is forwarded back and forth.

Untrusted content stays contained

  • Message HTML is rendered in a sandbox: it is served from its own endpoint with a strict Content-Security-Policy that blocks scripts, objects and frames, and shown in a sandboxed iframe.
  • Request bin responses, which you can configure, are served with a sandboxing Content-Security-Policy and no content sniffing, and cannot set cookies or redirect headers.
  • Remote images and stylesheets load through an image proxy, so senders cannot see who opened a message or from where.
  • Attachments are always downloaded, never rendered inside the app.
  • Requests to URLs that customers supply (webhooks, link checks, inbound deliveries, voice callbacks, SCIM and the image proxy) refuse to connect to private, loopback and link-local addresses, checked at connection time so DNS tricks cannot bypass it.

Secrets and credentials

  • Inbox SMTP passwords, SMPP passwords, sandbox tokens, webhook signing secrets and SCIM tokens are encrypted at rest with AES-256-GCM.
  • If you upload an APNs key, only its public part is kept.
  • API keys are shown once and stored only as SHA-256 hashes; they can be read-only and can expire.
  • Passwords are hashed; two-factor secrets are encrypted.
  • All traffic to the web app and API uses TLS, and the app sends security headers; SMTP supports STARTTLS and implicit TLS, and refuses passwords on unencrypted connections when TLS is available. SMPP is offered over TLS on its own port, which we recommend; the plain SMPP port exists for clients that cannot use TLS.

Access control

  • Every team's data is isolated in every query; requests for another team's data are answered as if it did not exist.
  • Roles separate owners, admins and members; API keys cannot manage people, keys or SSO.
  • Two-factor authentication, team single sign-on (OIDC and SAML) and sign-in restricted to company domains are available.
  • Sign-in, password reset, SMTP and SMPP connections, and failed SMTP and SMPP logins are rate limited.
  • Mock identity providers can be restricted to signed-in team members.

Operations, accountability and retention

  • The Service runs on Amazon Web Services in the EU (Ireland). Server access is limited to named operators using SSH keys from allow-listed addresses, and secrets are kept in a managed secrets store.
  • The database is backed up nightly to encrypted, access-restricted storage, kept for 30 days.
  • Each team has an audit log of changes to inboxes, keys, webhooks, identity providers and forwarding, and of every forwarded message.
  • Captured content is deleted automatically according to the plan's retention and each inbox's limit, and stored objects of deleted messages are purged. See the privacy policy.
  • Service status and incidents are published on the status page.

Responsible disclosure

We welcome reports from security researchers. If you believe you have found a vulnerability:

  • Email security@testlie.com with a description, the steps to reproduce it and the impact you expect. Our security.txt has the same contact.
  • Test only against accounts and data you own. Do not access, modify or delete other customers' data, do not degrade the service (no denial-of-service or load testing), and do not use social engineering or physical attacks.
  • Do not send mail or messages through the service to people who have not agreed to it, and follow our acceptable use policy.
  • To report abuse of the service rather than a vulnerability (for example a phishing page), email abuse@testlie.com.
  • Give us reasonable time to fix the issue before disclosing it publicly.

We will acknowledge your report within 3 business days, keep you updated, and credit you if you wish. We will not pursue legal action against good-faith research that follows these rules.

Out of scope: reports from automated scanners without a demonstrated impact, missing headers without a concrete attack, rate limits on non-sensitive endpoints, and the fact that mock identity providers let anyone who can reach their login screen sign in as a test user (that is their purpose; use a protected IdP to restrict it).