Skip to content

Security

Your key is public. Your email isn’t up for grabs.

Sending from the frontend means your public key sits in your page source, where anyone can copy it. We designed Frontmail around that fact. Below is every attack we know of, what stops it, and – openly – what remains.

Read the full threat modelReport a vulnerability

What actually protects you

Web origins and headers can be faked by any script. So we rely on things an attacker can’t change.

  • Your templates

    A public key can only send templates you wrote. The caller fills in params – never the template itself.

  • Locked content

    When the caller may choose the recipient, the rest of the email is locked: links only to your domains, fixed sender, no HTML from outside.

  • Human check and limits

    CAPTCHA on your own Turnstile keys, limits per IP, key, organization and recipient – all checked before a credit is spent.

Attacks and how Frontmail stops them

  • Phishing from your domain

    The attack
    Someone copies your key and sends your “reset your password” template to strangers – with their own link. It comes from your domain and passes SPF and DKIM.
    How Frontmail stops it
    Templates whose recipient comes from params get locked content: every link must point to your allowed domains (also plain-text links, look-alike domains and tricks like you.com@evil.com), the sender and Reply-To are fixed, CAPTCHA is mandatory and each recipient gets only a few such emails a day. It is all checked before sending.
    What remains
    Your legitimate email can still reach a stranger – with nothing in it the attacker controls.

  • Spam flooding your form

    The attack
    A script fills your contact form thousands of times.
    How Frontmail stops it
    CAPTCHA per template, per-IP limits (IPv6 counted per network), per-key and per-organization limits, anomaly detection, server-side headless-browser and block-list checks.
    What remains
    Without CAPTCHA a patient attacker with many IP addresses can still get some through.

  • Faked origin, scripts and fake apps

    The attack
    Requests from a script that pretends to be your website – or sends no origin at all.
    How Frontmail stops it
    Requests without an origin are refused unless you enable mobile apps. Web requests must pass your own Turnstile widget, issued on the same domain.
    What remains
    A faked origin passes the allowlist; CAPTCHA and limits are what stop it.

  • Draining your credits or your card

    The attack
    Junk sends to burn your quota, your overdraft and your automatic top-ups.
    How Frontmail stops it
    Traffic with a public key never uses overdraft or triggers auto top-up unless you allow it. The hold queue has a cap. Auto top-up has monthly limits.
    What remains
    Junk that passes CAPTCHA can use your regular credits – never extra money.

  • Blocking your form for real visitors

    The attack
    A cheap flood of invalid requests to exhaust your limits.
    How Frontmail stops it
    Organization-wide limits count only requests that passed the template and CAPTCHA checks. A firewall at the edge absorbs the rest, and our servers accept traffic only through it.
    What remains
    A very large distributed attack can slow things down.

  • A leaked private key

    The attack
    The secret key ends up in browser code and someone copies it.
    How Frontmail stops it
    Our browser SDKs refuse to run with a private key, and the API refuses private keys from web pages unless you opt in. Keys are stored only as hashes and can be rotated instantly.
    What remains
    Whoever holds your private key can send without CAPTCHA – keep it on your server.

  • Malicious attachments

    The attack
    Malware sent to you or to a recipient as a file.
    How Frontmail stops it
    Attachments from the browser are off unless a template allows them. Executables, scripts, HTML, disk images and macro documents are blocked – also behind tricks like invoice.pdf.exe or hidden characters.
    What remains
    Ordinary documents can still carry bad content; your mail antivirus is the last line.

  • Injecting HTML or script

    The attack
    Putting <script>, tracking pixels or fake forms into a param.
    How Frontmail stops it
    Params are always escaped, HTML params go through an allowlist sanitizer, dangerous URLs are neutralized and line breaks can’t inject email headers.
    What remains
    Nothing known.

  • Taking over your account

    The attack
    Guessed passwords, stolen sessions, a stolen mailbox.
    How Frontmail stops it
    Two-factor authentication on every sign-in method, sign-in limits, one-time reset links that sign out all devices, e-mail changes confirmed from the old address, roles with least privilege and an audit log.
    What remains
    Turn on 2FA – it is the one step only you can take.

  • Reading other people’s data

    The attack
    Trying to reach another customer’s messages, form submissions or files.
    How Frontmail stops it
    Every lookup is scoped to your organization – history, templates and attached files. History is readable only with the private key or by your team.
    What remains
    Nothing known.

  • Harassing one person

    The attack
    Using a template with a dynamic recipient to bombard one address with emails.
    How Frontmail stops it
    Each address gets only a few such emails a day from your organization, auto-replies included. Addresses that bounce or complain are suppressed automatically.
    What remains
    A handful of your legitimate emails a day.

  • A compromised SDK

    The attack
    Malicious code slipped into the script your website loads.
    How Frontmail stops it
    Releases are built without secrets and published with provenance. Load the SDK from a pinned version with an integrity hash and your browser rejects any change.
    What remains
    Pin the version – an unversioned URL always loads the latest.

Your part

Five minutes in Security settings close the gaps only you can close.

  • Add your domains to Allowed origins.
  • Add your own Turnstile keys and require CAPTCHA on public forms.
  • Use a dynamic recipient only where you need it and list your link domains.
  • Keep the private key on your server.
  • Turn on two-factor authentication for your whole team.

Why we tell you what remains

No service that sends email from the browser can make a public key secret. We would rather show you exactly where the limits are than promise something no one can deliver.

Read the full threat model