Bedrohungsmodell

Mit Frontmail senden Sie E-Mails direkt aus dem Browser. Das ist bequem, bedeutet aber, dass ein Teil Ihrer Integration in Code steckt, den jeder lesen und kopieren kann. Diese Seite listet jeden uns bekannten Angriff auf dieses Modell auf, beschreibt, wie Frontmail sich dagegen wehrt, was Sie selbst einrichten sollten, und – ganz offen – welches Risiko bleibt. Wenn Ihnen etwas fehlt, schreiben Sie an security@frontmail.dev.

Das Grundmodell

• Der öffentliche Schlüssel ist öffentlich. Er steht im Quelltext Ihrer Seite. Behandeln Sie ihn wie einen Benutzernamen, nicht wie ein Passwort. Jeder kann ihn kopieren und die API aus einem Skript aufrufen.
• Der Origin-Header ist keine Authentifizierung. Browser setzen ihn ehrlich, aber ein Skript kann jeden beliebigen Wert senden. Erlaubte Domains verhindern, dass andere Websites Ihren Schlüssel in den Browsern ihrer Besucher verwenden – einen entschlossenen Angreifer halten sie nicht auf.
• Was Sie wirklich schützt, ist das, was der Angreifer nicht ändern kann:
  1. die Vorlage – der Angreifer kann nur Ihre Vorlagen senden und nur deren Parameter befüllen,
  2. das CAPTCHA (Turnstile) – jede Sendung kostet eine menschenähnliche Lösung,
  3. Limits – pro IP, pro Schlüssel, pro Organisation, pro Empfänger – und Ihre Credits.
• Der private Schlüssel ist ein Geheimnis. Er gehört ausschließlich auf Ihren Server. Er umgeht die Liste erlaubter Domains und das CAPTCHA und kann Ihren Nachrichtenverlauf lesen.

Der Rest dieser Seite folgt aus diesen vier Punkten.

Angriffe und Abwehr

1. Phishing von Ihrer Domain (der wichtigste)

Angriff. Eine Vorlage übernimmt ihren Empfänger aus Parametern – ein Passwort-Reset, eine Benachrichtigung, eine Newsletter-Bestätigung. Der Angreifer kopiert Ihren öffentlichen Schlüssel, sendet diese Vorlage an ein Opfer und setzt in reset_url seine eigene Website ein. Die E-Mail kommt von Ihrer Domain, besteht SPF und DKIM, sieht genau aus wie Ihre und verlinkt auf den Angreifer.

Was Frontmail tut. Eine Anfrage mit öffentlichem Schlüssel an eine Vorlage mit dynamischem Empfänger erhält einen gesperrten Inhalt:

• CAPTCHA ist Pflicht (dynamic_recipient_requires_captcha),
• jeder Link muss auf Ihre erlaubten Domains zeigen – geprüft werden Links in Attributen, CSS, reinem Text (auch bloßes evil.com/login, das Mailprogramme in Links verwandeln) und im Betreff, einschließlich Tricks wie https://you.com@evil.com, Backslashes, Unicode-Doppelgänger-Domains und kodierter Zeichen (link_not_allowed),
• Absenderadresse, Absendername und Reply-To dürfen nicht aus Parametern stammen (dynamic_field_not_allowed),
• keine HTML-Parameter, Textparameter höchstens 500 Zeichen,
• jeder Empfänger erhält von Ihrer Organisation höchstens 5 solcher E-Mails pro Tag (einstellbar).

Alles wird geprüft, bevor ein Credit verbraucht wird. Automatische Antworten sind auf dieselbe Weise gesperrt.

Was Sie tun sollten. Füllen Sie Sicherheit → Erlaubte Link-Domains aus, wenn Ihre Links woandershin führen als auf die Domain Ihrer Website. Richten Sie eigene Turnstile-Schlüssel ein. Vorlagen, die nur Ihr Server sendet (Bestellbestätigungen, im Backend erzeugte Passwort-Resets), sollten mit dem privaten Schlüssel gesendet werden.

Restrisiko. Der Angreifer kann Ihre legitime E-Mail weiterhin an Fremde senden – etwa „Bestätigen Sie Ihr Newsletter-Abonnement“ mit einem Link auf Ihre Website. Sie enthält nichts, was er kontrolliert, taugt also nicht zum Phishing, kann aber lästig sein. Das Limit pro Empfänger und das CAPTCHA halten das klein. Reiner Text ohne Links (etwa „Rufen Sie diese Nummer an“) in einem Textparameter ist innerhalb von 500 Zeichen weiterhin möglich – beschränken Sie dynamische Textparameter auf das, was die E-Mail wirklich braucht.

2. Spam in Ihr eigenes Postfach

Angriff. Ein Skript überflutet die Vorlage Ihres Kontaktformulars mit Müll.

Was Frontmail tut. Limit pro IP (standardmäßig 10 Anfragen / 60 s, IPv6 pro /64-Netz gezählt), Limits pro Schlüssel und pro Organisation, Anomalieerkennung, serverseitige Prüfungen auf Headless-Browser und Blockliste, optionales CAPTCHA pro Vorlage.

Was Sie tun sollten. Schalten Sie für öffentliche Formulare CAPTCHA verlangen ein. Nutzen Sie die Blockliste für bekannte Spam-Werte.

Restrisiko. Ohne CAPTCHA kommt ein geduldiger Angreifer mit wechselnden IP-Adressen durch die Limits. Mit CAPTCHA muss er für jede E-Mail einen Lösungsdienst bezahlen.

3. API-Aufrufe aus einem Skript oder einer gefälschten „App“

Angriff. Der Angreifer sendet Anfragen ohne Browser, mit gefälschtem Origin oder ganz ohne.

Was Frontmail tut. Anfragen ohne Origin und Referer (typisch für Skripte) werden abgelehnt, sofern Sie nicht Mobile Apps erlauben eingeschaltet haben – auch wenn Ihre Liste erlaubter Domains leer ist. Nur Organisationen mit dieser Option verwenden das gemeinsame mobile CAPTCHA von Frontmail; alle anderen müssen Ihr eigenes Turnstile-Widget bestehen, und dessen Token muss auf der anfragenden Domain ausgestellt worden sein.

Was Sie tun sollten. Lassen Sie Mobile Apps erlauben aus, solange Sie keine native App haben. Serverseitiger Code sollte den privaten Schlüssel verwenden.

Restrisiko. Ein gefälschter Origin besteht die Liste erlaubter Domains weiterhin; aufgehalten wird er durch CAPTCHA und die Limits (siehe Punkt 2).

4. Ihre Credits oder Ihre Karte leeren

Angriff. Mit Ihrem öffentlichen Schlüssel sendet der Angreifer so viele E-Mails, wie die Limits zulassen, um Ihr monatliches Kontingent zu verbrennen – und, wenn er könnte, auch Ihre Überziehung und automatische Aufladungen.

Was Frontmail tut.

• Traffic mit öffentlichem Schlüssel nutzt die Überziehung nicht und löst die automatische Aufladung nicht aus, sofern Sie das nicht ausdrücklich erlauben (Abrechnung → Ausgaben durch Traffic mit öffentlichem Schlüssel).
• Die Warteschlange zurückgehaltener E-Mails hat eine Obergrenze; darüber hinaus werden Anfragen abgelehnt statt eingereiht, sodass Müll nicht die Credits aufbraucht, die Sie später kaufen.
• Die automatische Aufladung hat eine monatliche Obergrenze für Anzahl und Ausgaben.

Was Sie tun sollten. Behalten Sie die Standardeinstellungen, nutzen Sie CAPTCHA und beachten Sie die E-Mails zur Anomalieerkennung.

Restrisiko. Ihr reguläres Kontingent und Ihre Credit-Pakete können weiterhin durch Müll verbraucht werden, der an CAPTCHA und Limits vorbeikommt. Das kostet Sie Credits, aber kein zusätzliches Geld.

5. Ihr Formular für echte Besucher blockieren

Angriff. Eine billige Flut ungültiger Anfragen erschöpft die Limits Ihrer Organisation, sodass echte Besucher 429 erhalten.

Was Frontmail tut. Organisationsweite Limits und die Anomalieerkennung zählen nur Anfragen, die die Prüfungen von Vorlage und CAPTCHA bestanden haben; davor gelten nur das Limit pro IP und ein großzügiger Flutschutz.

Restrisiko. Eine große verteilte Flut kann die Dinge weiterhin verlangsamen; die Firewall an der Edge (WAF) fängt das meiste davon ab.

6. Die Firewall umgehen

Angriff. Die Server von Frontmail direkt statt über das CDN aufrufen, um die Web Application Firewall zu umgehen und die Client-IP-Adresse zu fälschen.

Was Frontmail tut. Die Server akzeptieren nur Anfragen, die über unser CDN kamen, und vertrauen nur der vom CDN gemeldeten Client-IP-Adresse. Sie müssen nichts einrichten.

7. Ein durchgesickerter privater Schlüssel

Angriff. Der private Schlüssel landet im Browser-Code (oft nach einer Migration von EmailJS, dessen accessToken ein privater Schlüssel ist), und jemand kopiert ihn.

Was Frontmail tut. Die Browser-SDKs verweigern die Ausführung mit einem privaten Schlüssel (private_key_in_browser), und die API lehnt Anfragen mit privatem Schlüssel von einer Webseite ab, sofern Sie nicht Private Schlüssel im Browser erlauben eingeschaltet haben. Private Schlüssel werden nur als Hashes gespeichert.

Was Sie tun sollten. Legen Sie sk_… niemals in Frontend-Code oder in VITE_- / NEXT_PUBLIC_-Variablen ab. Ist er durchgesickert, erneuern Sie ihn sofort.

Restrisiko. Wer Ihren privaten Schlüssel besitzt, kann ohne CAPTCHA senden und Ihren Nachrichtenverlauf lesen (einschließlich Formulareinsendungen). Schützen Sie ihn wie ein Passwort.

8. Gefährliche Anhänge

Angriff. Schadsoftware als Anhang an Sie oder an einen dynamischen Empfänger senden.

Was Frontmail tut. Anhänge aus dem Browser sind ausgeschaltet, sofern die Vorlage sie nicht erlaubt. Ausführbare Dateien, Skripte, HTML/SVG, Disk-Images, Office-Dateien mit Makros und ähnliche Typen werden blockiert – auch hinter Tricks wie invoice.pdf.exe., Rechts-nach-links-Zeichen oder unsichtbaren Zeichen. Uploads mit öffentlichem Schlüssel haben ein tägliches Volumenlimit.

Restrisiko. Gewöhnliche Dokumente (PDF, DOCX) können weiterhin schädliche Inhalte tragen; der Virenschutz Ihres Mailprogramms ist die letzte Verteidigungslinie.

9. HTML oder Skripte in die E-Mail einschleusen

Angriff. <script>, Tracking-Pixel oder ein gefälschtes Formular in einen Parameter packen.

Was Frontmail tut. Parameter werden immer HTML-maskiert (auch mit {{{ }}}), html-Parameter werden per Allowlist bereinigt und können nicht aus Attributen ausbrechen, gefährliche URLs werden entschärft, Zeilenumbrüche werden aus Headern entfernt (keine Header-Injection), Schlüssel, die den Prototyp verunreinigen würden, werden verworfen.

10. Eine Person belästigen (Mail-Bombing)

Angriff. Mit einer Vorlage mit dynamischem Empfänger viele E-Mails an eine Adresse senden.

Was Frontmail tut. Tägliches Limit pro Empfänger (standardmäßig 5), geteilt mit automatischen Antworten; Sperrliste für Adressen mit Bounces oder Beschwerden.

11. Ihr Dashboard-Konto übernehmen

Angriff. Passwort erraten, Sitzung stehlen, Postfach stehlen.

Was Frontmail tut. Rate Limits bei der Anmeldung, Zwei-Faktor-Authentifizierung, die für jede Anmeldemethode durchgesetzt wird, Links zum Zurücksetzen des Passworts, die einmal funktionieren und alle Geräte abmelden, Änderungen der E-Mail-Adresse mit Bestätigung von der alten Adresse, Benachrichtigungen über neue Geräte, Rollen nach dem Prinzip der minimalen Rechte und ein Audit-Log.

Was Sie tun sollten. Aktivieren Sie 2FA und geben Sie Teammitgliedern die kleinste Rolle, die ausreicht.

12. Ihre Formulareinsendungen stehlen

Angriff. Den Nachrichtenverlauf oder Dateien anderer lesen.

Was Frontmail tut. Der Verlauf ist nur mit dem privaten Schlüssel oder für Mitglieder Ihrer Organisation lesbar; jede Abfrage ist auf Ihre Organisation beschränkt, auch bei Dateien, die an Vorlagen hängen.

13. Gefälschte Zustellereignisse

Angriff. Gefälschte Ereignisse „bounced“ oder „complained“ senden, um Ihre Kunden auf die Sperrliste zu setzen.

Was Frontmail tut. Webhooks der Anbieter werden per Signatur geprüft, wo der Anbieter das unterstützt, und immer über ein geheimes URL-Token; ein Ereignis betrifft nur den tatsächlichen Empfänger einer Nachricht.

Was Sie tun sollten. Richten Sie den Signaturschlüssel für Ihren Anbieter ein, wo er angeboten wird.

14. Ein kompromittiertes SDK

Angriff. Schadcode in dem Skript, das Ihre Website lädt.

Was Frontmail tut. Releases werden ohne Secrets gebaut und mit Provenance veröffentlicht, und die CI-Actions sind auf exakte Versionen festgelegt.

Was Sie tun sollten. Laden Sie das SDK von einer versionierten URL mit einem integrity-Attribut (siehe Browser-SDK) oder bündeln Sie das npm-Paket.

15. Frontmail in den Händen von Kriminellen

Angriff. Eine Phishing-Website nutzt ihr eigenes Frontmail-Konto, um gestohlene Passwörter an sich selbst zu senden – das passiert jedem Dienst dieser Art.

Was Frontmail tut. Bestätigte E-Mail-Adresse des Inhabers, Überwachung ungewöhnlichen Traffics, schnelle Sperrung gemeldeter Konten. Melden Sie Missbrauch an abuse@frontmail.dev.

Was in Ihrer Hand bleibt – Checkliste

• Tragen Sie Ihre Domains unter Erlaubte Websites ein.
• Hinterlegen Sie eigene Turnstile-Schlüssel und verlangen Sie CAPTCHA bei öffentlichen Formularen.
• Verwenden Sie dynamische Empfänger nur, wo nötig; füllen Sie Erlaubte Link-Domains aus.
• Lassen Sie Mobile Apps erlauben und Private Schlüssel im Browser erlauben aus, solange Sie sie nicht brauchen.
• Privaten Schlüssel nur auf dem Server; im Zweifel erneuern.
• Lassen Sie Überziehung und automatische Aufladung für den öffentlichen Schlüssel aus (Standard).
• Aktivieren Sie 2FA für alle in Ihrem Team.
• Laden Sie das SDK in einer festgelegten Version mit integrity.