So schützen Sie ein selbst gehostetes öffentliches Formular vor Spam, ohne echte Nutzer auszusperren

Klären Sie zunächst den Zweck des Formulars und den wahrscheinlichen Missbrauch

Welche Maßnahmen zum Spam-Schutz für ein selbst gehostetes Formular geeignet sind, hängt davon ab, wofür das Formular verwendet wird. Bei einem Kontaktformular, einer Kundenumfrage, einem Formular zur Kontoerstellung und einer Angebotsanfrage unterscheiden sich sowohl die Folgen eines Missbrauchs als auch die Kosten, wenn eine echte Einsendung abgelehnt wird.

Erfassen Sie zunächst, wer das Formular nutzt, welche Informationen es erhebt, wohin die Einsendungen gelangen und was anschließend geschieht. Wenn ein Formular eine E-Mail auslöst, einen CRM-Datensatz anlegt oder einen anderen Arbeitsablauf startet, kann wiederholtes Absenden durch Bots mehr als nur das Formular selbst beeinträchtigen.

• Bestimmen Sie, wer das Formular rechtmäßig nutzt. Berücksichtigen Sie dabei auch Menschen, die assistive Technologien oder ihnen unbekannte Geräte verwenden.
• Listen Sie die Datenfelder auf und kennzeichnen Sie, welche davon unbedingt erforderlich sind. Erheben Sie keine Angaben, die nicht dem Zweck des Formulars dienen.
• Halten Sie fest, mit welcher Art von Missbrauch Sie rechnen: unerwünschte Nachrichten, wiederholte Einsendungen, Kauderwelsch, ungültige Kontaktdaten oder Versuche, nachgelagerte Aktionen auszulösen.
• Notieren Sie die Folgen von Spam und von fälschlich blockierten legitimen Einsendungen. Eine blockierte Vertriebsanfrage kann schwerer wiegen als eine kleine Menge Umfragedaten geringer Qualität.

Prüfen Sie, was die Anwendung schützt – und was nicht

Beginnen Sie mit der offiziellen Dokumentation der Anwendung und der Version, die Sie tatsächlich einsetzen. Suchen Sie nach dokumentierten Funktionen wie CAPTCHA, einer Prüfung von Einsendungen, Feldvalidierung oder Einschränkungen für bestimmte E-Mail-Domains. Gehen Sie nicht davon aus, dass eine Einstellung vorhanden ist, nur weil ein anderes Produkt sie anbietet.

Unterscheiden Sie zwischen Schutzmaßnahmen der Anwendung und solchen, die an anderer Stelle bereitgestellt werden. Für Ihre Website, Anwendung, Hosting-Umgebung und weitere Dienste können jeweils unterschiedliche Zuständigkeiten gelten. Klären Sie, an welcher Stelle Einsendungen validiert und missbräuchliche Anfragen begrenzt werden können. Eine Maßnahme auf einer Ebene bedeutet nicht, dass alle Ebenen abgedeckt sind.

Die Dokumentation von HubSpot beschreibt beispielsweise CAPTCHA und das Blockieren bestimmter E-Mail-Domains oder kostenloser E-Mail-Anbieter als Optionen. Außerdem weist sie darauf hin, dass Methoden wie reCAPTCHA und die Erkennung von Kauderwelsch auf bestimmte Verhaltensweisen oder Spam-Arten abzielen. Das sind Beispiele und keine Garantie dafür, dass Ihre selbst gehostete Anwendung dieselben Funktionen bietet.

• Prüfen Sie die offizielle Dokumentation für die eingesetzte Anwendungsversion und Konfiguration.
• Stellen Sie fest, ob die Validierung sowohl auf dem Server als auch im Browser erfolgt. Prüfungen, die nur im Browser stattfinden, sollten nicht als Sicherheitsgrenze gelten.
• Klären Sie, ob Ihre umgebende Infrastruktur Anfragelimits oder andere passende Schutzmaßnahmen bietet und ob diese für den Formular-Endpunkt gelten.
• Dokumentieren Sie, welche Schutzmaßnahmen aktiviert sind, wo sie greifen und wer für ihre Überprüfung zuständig ist.

Stellen Sie verhältnismäßige Schutzmaßnahmen zusammen

Übertragen Sie nicht einem einzelnen Filter die Verantwortung für jede Art von Missbrauch. Ein sinnvoller Ausgangspunkt ist die serverseitige Validierung der erwarteten Felder und Formate, ergänzt durch eine maßvolle Begrenzung wiederholter Einsendungen, sofern Ihre Anwendung oder Infrastruktur dies unterstützt. Prüfen Sie Werte anhand des Formularzwecks und nicht anhand von Annahmen darüber, wie alle legitimen Nutzer schreiben.

Berücksichtigen Sie Missbrauchssignale nur, wenn sie zu einer besseren Entscheidung beitragen. Wiederholte Versuche, unplausible Feldmuster oder Inhalte, die nicht zum Formular passen, können eine Prüfung oder zusätzliche Verifizierung rechtfertigen. Behandeln Sie jedes einzelne Signal als fehlbar: Ein gemeinsam genutztes Netzwerk, ein ungewöhnlicher Name oder eine kurze Antwort beweisen keinen Missbrauch.

Sichern Sie auch nachgelagerte Aktionen ab. Wenn das Formular automatisch eine Antwort sendet, übernehmen Sie nicht ungeprüft öffentlich eingereichte Texte in diese E-Mail. Postmark warnt davor, dass ein ungeschütztes Formular dazu missbraucht werden kann, über ein Autoresponder-System Spam zu versenden, wenn dieses vom Nutzer eingegebene Inhalte einfügt.

• Verlangen Sie die erforderlichen Angaben und validieren Sie sie serverseitig. Wenn eine Eingabe ungültig ist, zeigen Sie eine klare Korrekturmeldung an.
• Setzen Sie Anfragelimits nur dort ein, wo dies möglich ist, und passen Sie sie an die legitime Nutzung des Formulars an. Bedenken Sie, dass sich mehrere echte Nutzer ein Netzwerk teilen können.
• Sorgen Sie für eine sichere Verarbeitung der Einsendungen: Prüfen Sie, welche E-Mails, Datensätze oder anderen automatisierten Aktionen ausgelöst werden.
• Lassen Sie unsichere Einsendungen prüfen oder zusätzlich verifizieren, statt sie stillschweigend zu verwerfen – insbesondere, wenn ein Fehlalarm schwerwiegende Folgen hätte.

Wählen Sie CAPTCHA, Honeypots und Verifizierung mit Blick auf die Nutzer aus

CAPTCHA kann eine zusätzliche Hürde für manche automatisierten Einsendungen schaffen, verursacht aber auch Aufwand für legitime Nutzer. Prüfen Sie, ob die Herausforderung barrierefrei ist, auf Mobilgeräten funktioniert und eine praktikable Alternative bietet, falls jemand sie nicht lösen kann. Lesen Sie die Datenschutzinformationen des Anbieters, bevor Sie Besucherdaten oder Interaktionssignale an einen Drittanbieter übermitteln.

Ein Honeypot ist ein Feld, das vor gewöhnlichen Nutzern verborgen, aber für manche automatisierten Formularausfüller erkennbar sein soll. Postmark beschreibt ihn als Ergänzung zum Formularschutz, nicht als vollständige Abwehr. Testen Sie das Verhalten mit Ihrem Theme, Ihren Skripten, der automatischen Browser-Vervollständigung und assistiven Technologien, damit echte Nutzer nicht durch ein Feld benachteiligt werden, das sie nicht sehen können.

Eine Verifizierung per E-Mail oder auf anderem Weg kann sinnvoll sein, wenn der Zweck des Formulars den zusätzlichen Schritt rechtfertigt. Für eine einfache Kontaktanfrage kann sie übertrieben sein. Wenn Sie E-Mail-Anbieter oder Domains einschränken, bedenken Sie, ob dadurch Menschen ausgeschlossen werden, die berechtigterweise solche Adressen verwenden.

• Vergleichen Sie jede Option danach, wie viel Missbrauch sie voraussichtlich reduziert, wie viel zusätzlichen Aufwand sie verursacht und welche Auswirkungen sie auf Barrierefreiheit, Datenschutz und Wartung hat.
• Kombinieren Sie nicht standardmäßig mehrere Herausforderungen. Führen Sie eine Schutzmaßnahme nur ein, wenn Sie erklären können, welches Problem sie löst.
• Testen Sie das Formular mit Tastaturnavigation, assistiven Technologien, mobilen Layouts und gängigen Funktionen zur automatischen Vervollständigung.
• Bieten Sie einen klaren Alternativweg oder Kontaktkanal an, falls ein legitimer Besucher eine Herausforderung nicht bewältigen kann.

Planen Sie den Umgang mit Fehlalarmen und die Wiederherstellung

Jeder Filter kann eine echte Einsendung ablehnen. Postmark weist ausdrücklich darauf hin, dass aggressive Filter legitime Nutzer blockieren können. Bevor Sie eine strenge Regel aktivieren, legen Sie fest, wie Sie Fehler erkennen und wie Besucher sie beheben können.

Machen Sie deutlich, was als Nächstes geschieht. Wenn eine Einsendung abgelehnt wird oder ein weiterer Schritt nötig ist, erklären Sie dem Nutzer, was zu tun ist, ohne interne Sicherheitsdetails offenzulegen. Stellen Sie bei wichtigen Formularen einen alternativen Kontaktweg bereit und sorgen Sie dafür, dass ihn jemand überwacht.

Behalten Sie genügend Einblick in den Betrieb, um Probleme untersuchen zu können. Erheben oder speichern Sie jedoch nicht mehr personenbezogene Daten, als Ihr Team benötigt. Legen Sie gemäß Ihren eigenen Datenschutz- und Governance-Anforderungen fest, wer auf Einsendungen zugreifen darf und wie lange sie aufbewahrt werden.

• Richten Sie, sofern Ihre Konfiguration dies unterstützt, eine Möglichkeit ein, abgelehnte oder in Quarantäne verschobene Einsendungen zu erkennen.
• Bieten Sie Menschen, die keine Einsendung übermitteln können, einen Weg zur Wiederherstellung und testen Sie auch diesen.
• Prüfen Sie Domain-Sperren und strenge Inhaltsregeln auf unbeabsichtigte Ausschlüsse.
• Legen Sie fest, wer mutmaßliche Fehlalarme prüft und wie schnell diese Person handeln sollte.

Beobachten Sie Muster und überprüfen Sie Ihre Einstellungen regelmäßig

Eine Schutzmaßnahme, die für ein bestimmtes Formular oder eine bestimmte Zielgruppe funktioniert, kann ungeeignet werden, wenn das Formular stärker genutzt wird oder sich sein Zweck ändert. Prüfen Sie nach dem Start die Muster bei den Einsendungen und Rückmeldungen der Nutzer. Überdenken Sie die Schutzmaßnahmen erneut, wenn sich das Volumen, die Zielgruppe, die erhobenen Daten oder die nachgelagerten Aktionen ändern.

Achten Sie auf Trends, statt eine einzelne ungewöhnliche Einsendung als Beweis zu werten. Ein plötzlicher Anstieg wiederholter Spam-Einträge kann eine gezielte Anpassung erfordern. Meldungen, dass legitime Nutzer keine Einsendung übermitteln können, können dagegen dafür sprechen, eine Regel zu lockern oder den Ausweichweg zu verbessern. Dokumentieren Sie Änderungen, damit Sie erkennen können, ob eine neue Schutzmaßnahme geholfen oder ein neues Problem verursacht hat.

• Erfassen Sie, sofern verfügbar, nützliche Betriebsdaten wie angenommene, abgelehnte und überprüfte Einsendungen.
• Achten Sie auf Meldungen über fehlende Einsendungen und prüfen Sie, ob sie herausgefiltert oder nie empfangen wurden.
• Überprüfen Sie die Einstellungen nach Änderungen am Formular, an der Anwendung, der Zielgruppe oder den durch eine Einsendung ausgelösten Aktionen.
• Prüfen Sie Datenschutzinformationen, den Zugriff auf erhobene Daten und die Aufbewahrungsfristen erneut, wenn sich das Formular weiterentwickelt.

Checkliste vor dem Start: Missbrauch und echte Nutzung testen

Testen Sie vor der Veröffentlichung den gesamten Weg einer Einsendung – vom Formular bis zu dem Ort, an dem Mitarbeitende die Einträge empfangen oder prüfen. Verwenden Sie Testfälle, die sowohl Ihre tatsächlichen Nutzer als auch die Missbrauchsmuster abbilden, die Sie eindämmen möchten. Vergewissern Sie sich, dass eine abgelehnte Einsendung nicht ohne Erklärung verschwindet und eine angenommene Einsendung am vorgesehenen Ziel ankommt.

Wenn das Formular in einer selbst gehosteten Anwendung läuft, kann Ihr Hosting Teile der umgebenden Infrastruktur übernehmen, ohne Entscheidungen über Formulardaten, Zugriff oder Moderation zu ersetzen. Airbip bietet beispielsweise die verwaltete Bereitstellung von Geschäftsanwendungen als Docker-Workloads auf seinen Cloud-Servern an; Routing und TLS-Zertifikate werden dabei über Traefik und Let’s Encrypt automatisiert. Diese Hosting-Funktionen belegen nicht, dass eine bestimmte Formularanwendung Spam-Schutz bietet. Prüfen Sie die Dokumentation der Anwendung und entscheiden Sie, wie Einsendungen verwaltet werden sollen.

• Übermitteln Sie gültige Testeingaben, die unterschiedliche legitime Nutzer, Geräte und Schreibweisen abbilden.
• Testen Sie fehlende Felder, ungültige Formate, wiederholte Versuche und die konkreten Missbrauchsmuster, die Sie ermittelt haben.
• Prüfen Sie die Nutzung per Tastatur und mit assistiven Technologien, die Bedienbarkeit auf Mobilgeräten, Alternativen zu Herausforderungen und die Bestätigungsnachricht.
• Vergewissern Sie sich, dass Einsendungen, abgelehnte Einträge und automatische Antworten wie vorgesehen verarbeitet werden.
• Stellen Sie sicher, dass Mitarbeitende wissen, wie sie fehlende oder markierte Einsendungen finden und einem blockierten Nutzer helfen können.
• Dokumentieren Sie vor dem Start die Schutzmaßnahmen, Testergebnisse, die zuständige Person für die Prüfung und den Weg zur Wiederherstellung.