Kurz gesagt
Ein Kontaktformular ohne Tracking und Spam braucht nur HTML und ein kleines Programm auf dem Server. Ein verstecktes Feld, eine signierte Zeitmarke und eine Zählung je Netzadresse erschweren Bots das Absenden, ohne Cookies, Captcha oder Skript im Browser. Der Server prüft alles und schickt die Anfrage nur an Ihr Postfach.
Das Wichtigste in Kürze
- Ein Formular kommt ohne JavaScript aus: Das HTML schickt die Eingaben an ein Programm auf dem Server, das alles prüft und Fehler als neue Seite zurückgibt.
- Gegen Spam wirken mehrere Prüfungen zusammen: Herkunft der Anfrage, ein für Menschen verstecktes Feld, eine signierte Zeitmarke und eine Zählung je Netzadresse.
- Ein einfacher Hash einer IP-Adresse lässt sich laut ENISA in rund zwei Minuten zurückrechnen. Für den Zähler braucht es einen geheimen, wechselnden Schlüssel.
- Eine automatische Bestätigung an die eingetragene Adresse öffnet ein Formular für Angriffe auf fremde Postfächer. Bleibt die Mail beim Betreiber, entfällt dieser Weg.
- Wer eine Prüfung nicht besteht, muss das erfahren: Bei Fehlern oder zu vielen Anfragen bleiben die Eingaben erhalten, und die Seite nennt einen anderen Weg zu Ihnen.
Warum kommt ein Kontaktformular ohne Captcha aus?
An einem Kontaktformular gibt es für Bots wenig zu holen: kein Konto, keine Zahlungsdaten, nur den Versand einer E-Mail an Sie. Dafür reichen nach unserer Einschätzung Prüfungen auf dem Server. Ein Captcha schließt dagegen manche Menschen aus und bindet oft einen fremden Dienst ein.
Ohne Tracking heißt hier: keine Cookies, keine Analyse-Skripte und keine Anfragen an fremde Server beim Aufruf oder Absenden. Ein Captcha ist ein Test, der Menschen von Programmen unterscheiden soll. Bei einem einfachen Anfrageformular stehen ihm drei Nachteile gegenüber:
- Manche Menschen scheitern daran. Das World Wide Web Consortium (W3C) schreibt, dass ein Captcha Menschen mit Behinderungen oft daran hindert, den Vorgang abzuschließen (W3C-Notiz zu Captchas, Entwurf vom 16.12.2021 (externe Website)).
- Der Schutz ist begrenzt. Forschende der University of California, Irvine, haben reCAPTCHA v2 über 13 Monate mit mehr als 3.600 Personen untersucht. Ihr Schluss: hohe Kosten und keine Sicherheit (Searles u. a., Vorabdruck (externe Website)).
- Ein fremder Dienst lädt mit. reCAPTCHA setzt laut Google ein eigenes Cookie (reCAPTCHA-FAQ von Google (externe Website)) und lädt sein Skript von Googles Servern (Anleitung zu reCAPTCHA v3 (externe Website)). Bei unserer Messung am 09.11.2026 wogen die beiden Skripte zusammen rund 359.000 Byte (gzip). Die HTML-Datei unserer Kontaktseite wog 9.720 Byte. Für sein Cloud-Produkt, früher reCAPTCHA Enterprise, sagt Google zu, die übermittelten Daten nur für diesen Dienst zu nutzen und nicht für personalisierte Werbung (Service Terms von Google Cloud (externe Website)). Das Skript läuft trotzdem im Browser Ihrer Besucher.
Auch Dienste ohne Rätsel, etwa Cloudflare Turnstile, führen ein Skript im Browser aus (Turnstile-Anleitung (externe Website)).
Eine ernst zu nehmende Stimme spricht für Captchas. Das National Cyber Security Centre der Schweiz (NCSC) empfiehlt sie für Formulare, damit Angreifer sie nicht missbrauchen, um fremde Postfächer mit Bestätigungsmails zu füllen (NCSC-Wochenrückblick 6/2026 (externe Website)). Schickt Ihr Formular gar keine Mail an die eingetragene Adresse, entfällt dieser Angriffsweg. Wie das geht, beschreibt der Abschnitt E-Mails an Fremde. Bei Benutzerkonten, Anmeldungen oder Formularen, die Angreifer gezielt ins Visier nehmen, kann ein Captcha nach unserer Einschätzung richtig bleiben.
Erledigt, wenn Sie wissen, was Ihr Formular auslöst: nur eine Mail an Sie oder auch Mails an fremde Adressen, Konten oder Downloads.
Wie funktioniert ein Formular ohne JavaScript?
Das HTML schickt die Eingaben mit POST an ein kleines Programm auf dem Server. Das Programm prüft jedes Feld, baut bei Fehlern die Seite mit Hinweisen neu auf und leitet nach dem Absenden auf eine Danke-Seite weiter. Im Browser läuft dafür kein Skript.
Das Attribut action nennt die Adresse des Programms, method="post" überträgt die Felder im Körper der Anfrage (MDN zu Formulardaten (externe Website)). Das Programm kann eine Funktion bei Ihrem Hoster sein, etwa ein Edge Script bei Bunny (externe Website). Ein eigener Server und eine Datenbank sind dafür nicht nötig.
<form method="post" action="/formular/senden">
<label for="name">Name</label>
<input id="name" name="name" required autocomplete="name">
<label for="email">E-Mail</label>
<input id="email" name="email" type="email" required autocomplete="email">
<label for="nachricht">Nachricht</label>
<textarea id="nachricht" name="nachricht" required></textarea>
<!-- Falle für Bots: per CSS aus dem Bild geschoben, Namen frei wählen -->
<div class="falle" aria-hidden="true">
<label for="firma-url">Bitte leer lassen</label>
<input id="firma-url" name="firma-url" tabindex="-1" autocomplete="off">
</div>
<button>Absenden</button>
</form>Auf dem Server gehören drei Dinge dazu:
- Jedes Feld erneut prüfen. Prüfungen im Browser lassen sich umgehen (OWASP-Hinweise zur Eingabeprüfung (externe Website)). Sie helfen beim Ausfüllen und ersetzen die Prüfung auf dem Server nicht.
- Fehler als Text zurückgeben. Die Seite kommt mit einer Fehlerliste über dem Formular zurück, und alle Eingaben stehen wieder in den Feldern.
- Nach dem Absenden weiterleiten. Mit dem Status 303 ruft der Browser die Danke-Seite als neue Anfrage ab (RFC 9110, Abschnitt 15.4.4 (externe Website)). Ein Neuladen zeigt dann nur diese Seite und sendet die Anfrage nicht ein zweites Mal.
Die Kopfzeile Content-Security-Policy kann mit form-action 'self' Formulare auf die eigene Adresse beschränken (MDN zu form-action (externe Website)). Wer gar kein JavaScript ausliefert, verbietet Skripte dort ganz. Was fremde Skripte für die Reaktionszeit Ihrer Seite bedeuten, erklärt unser Beitrag zu den Core Web Vitals. Was sonst noch zur technischen Grundlage einer Firmenwebsite gehört, erklärt unser Leitfaden zu technischem SEO.
Erledigt, wenn das Formular bei abgeschaltetem JavaScript vollständig funktioniert und Fehler als Text vor den Feldern stehen.
Wie erkennen Sie Bots ohne Captcha?
Prüfen Sie jede Anfrage auf dem Server in mehreren Schichten: Stammt sie von Ihrer Website, ist das versteckte Feld leer, ist die signierte Zeitmarke gültig, und liegt die Zahl der Anfragen unter Ihrer Grenze? Jede Schicht allein lässt sich umgehen. Zusammen machen sie massenhaftes Absenden aufwendig.
| Prüfung | Was sie leistet | Grenze | Typischer Fehler |
|---|---|---|---|
| Herkunft der Anfrage | Der Server nimmt nur Anfragen an, die laut Origin von Ihrer eigenen Website kommen. | Programme können die Kopfzeile selbst setzen. Die Prüfung hält vor allem fremde Websites ab. | Nur den Anfang der Adresse vergleichen. Dann ginge auch eine fremde Domain durch, die mit Ihrem Namen beginnt. Vergleichen Sie die ganze Adresse. |
| Verstecktes Feld (Honeypot) | Menschen sehen das Feld nicht. Füllt es ein Programm aus, verwirft der Server die Anfrage. | Bots, die für genau Ihr Formular geschrieben sind, lassen es leer. | Das Feld nur mit CSS verstecken. Ohne aria-hidden und tabindex="-1" geraten Tastatur- und Screenreader-Nutzer hinein. |
| Signierte Zeitmarke | Belegt, dass das Formular vom Server stammt und wann es ausgegeben wurde. Merkt sich der Server die benutzten Marken, gilt jede nur einmal. | Ein Bot kann abwarten und den Ablauf nachbauen. | Die Zeit ohne Signatur ins Formular schreiben oder die Mindestzeit so lang wählen, dass Menschen mit Autofill scheitern. |
| Zählung je Netzadresse | Bremst viele Anfragen aus derselben Quelle. | Bots mit vielen Adressen. Firmennetze teilen sich oft eine Adresse. | Jeden Fehlversuch mitzählen, sodass Tippfehler zur Sperre führen. |
Das W3C nennt versteckte Felder einen Ansatz, der sich selbst in handgeschriebenem HTML leicht umsetzen lässt (W3C-Notiz, Abschnitt 2.2.4 (externe Website)). Beim Herkunftsvergleich gilt laut OWASP-Hinweisen zu Cross-Site-Anfragen (externe Website): Fehlt die Kopfzeile, ist das kein Beweis für eine Anfrage von der eigenen Website.
Signiert heißt: Der Server bildet mit einem geheimen Schlüssel eine Prüfsumme (HMAC) über Zeitpunkt und Zufallswert. Ändert jemand den Wert, stimmt die Prüfsumme nicht mehr. OWASP beschreibt dieselbe Technik für Schutz-Tokens, die ein Server ausgibt und später wieder prüft.
Eine statische Seite kann diese Marke nicht tragen, denn sie ist für alle Besucher gleich und liegt fertig auf dem CDN. Ohne JavaScript gibt deshalb erst das Programm auf dem Server nach einem ersten Schritt das eigentliche Absende-Formular aus. So entsteht die Marke frisch für jede Anfrage.
Erledigt, wenn Sie alle vier Prüfungen auf dem Server haben, jede mit eigenem Fehlerfall, und das versteckte Feld für Hilfsmittel verborgen ist.
Wie zählen Sie Anfragen, ohne IP-Adressen zu speichern?
Bilden Sie aus der IP-Adresse und einem geheimen, täglich wechselnden Schlüssel einen Prüfwert, und zählen Sie nur diesen Wert. Der Prüfwert verfällt nach einem Tag. Ein Hash ohne Schlüssel reicht nicht, denn IPv4 kennt nur rund 4,3 Milliarden Adressen, die sich schnell durchprobieren lassen.
Die EU-Agentur für Cybersicherheit (ENISA) hat das durchgerechnet. Einen SHA-256-Wert einer IPv4-Adresse konnte 2019 ein gewöhnlicher Laptop in rund zwei Minuten zurückrechnen. ENISA rät deshalb zu Verfahren mit geheimem Schlüssel wie einem Message Authentication Code, also zur selben Technik wie bei der Zeitmarke (ENISA, Pseudonymisation techniques, S. 28 (externe Website)).
Worauf es in der Praxis ankommt:
- Schlüssel getrennt halten. Er liegt als geheime Variable beim Hoster und nicht im Code. Leiten Sie daraus je Tag einen neuen Schlüssel ab, und lassen Sie die Zählerstände spätestens am Ende des Tages verfallen.
- Den Anschluss zählen. Bei IPv6 hat ein einzelner Anschluss viele Adressen, oft sogar mehr als ein ganzes /64-Netz (RFC 6177 (externe Website)). Zählen Sie deshalb das Präfix, sonst lässt sich die Grenze mit jeder neuen Adresse umgehen.
- Erst vor dem Versand zählen. Wer sich vertippt, verbraucht so keinen Versuch.
- Einen zweiten Weg anbieten. Hinter einer Firmen-Adresse stehen oft mehrere Menschen. Die Meldung bei zu vielen Anfragen nennt deshalb Ihre E-Mail-Adresse.
Erledigt, wenn weder IP-Adressen noch deren einfache Hashes gespeichert werden und der Schlüssel außerhalb des Codes liegt.
Wie verhindern Sie, dass Ihr Formular E-Mails an Fremde schickt?
Schreiben Sie nie automatisch an die Adresse, die jemand ins Formular tippt. Die Anfrage geht nur an Ihr eigenes Postfach. Als Absender steht Ihre Domain, die Adresse aus dem Formular nur in der Antwortadresse. Zeilenumbrüche aus Eingaben dürfen nie in die Kopfzeilen der E-Mail gelangen.
- Keine automatische Bestätigung. Das NCSC beschreibt, wie Angreifer eine fremde Adresse in echte Formulare seriöser Unternehmen eintragen. Hunderte oder Tausende Bestätigungsmails verdecken dann eine einzige wichtige Nachricht, etwa die Warnung zu einer Überweisung oder Bestellung (NCSC-Wochenrückblick 6/2026 (externe Website)). Ohne automatische Bestätigung kann Ihr Formular dabei nicht mitmachen.
- Absender und Antwortadresse trennen. Steht die Adresse aus dem Formular als Absender in der Mail, scheitert die Zustellung leicht. Google verlangt für Direktversand, dass die Domain im Feld From zur geprüften Domain von SPF oder DKIM passt (E-Mail-Richtlinien von Google (externe Website)). Tragen Sie deshalb die eigene Domain als Absender ein und die Adresse der anfragenden Person in Reply-To (RFC 5322, Abschnitt 3.6.2 (externe Website)).
- Kopfzeilen schützen. Bei der sogenannten Email Injection schleusen Angreifer über Eingabefelder zusätzliche Kopfzeilen in eine Mail, etwa weitere Empfänger (CAPEC-134 (externe Website)). Nutzen Sie eine Bibliothek zum Versand, und verwerfen Sie Zeilenumbrüche in allen Feldern, die in Kopfzeilen landen.
Erledigt, wenn das Formular an genau eine feste Adresse schreibt und ein Test mit einem Zeilenumbruch im Namen keine zusätzliche Kopfzeile erzeugt.
Was sehen Menschen, wenn eine Prüfung anschlägt?
Jede Ablehnung braucht eine Antwort in Worten, und die Eingaben bleiben erhalten. Still verworfene Anfragen kosten echte Kunden, ohne dass Sie es bemerken. Nur beim versteckten Feld darf der Server so tun, als wäre alles gelungen, damit Bots nichts dazulernen.
| Fall | Was die Seite zeigt | Warum |
|---|---|---|
| Pflichtfeld fehlt oder E-Mail falsch | Fehlerliste über dem Formular mit Links zu den Feldern, Hinweis direkt am Feld, Eingaben bleiben | Das W3C empfiehlt eine Liste der Fehler vor dem Formular. |
| Sehr schnell abgesendet | Dasselbe Formular, ausgefüllt, mit der Bitte, es erneut abzusenden | Passwortmanager und Autofill füllen Formulare in Sekunden. Ein Mensch verliert so nichts. |
| Zu viele Anfragen | Seite mit Hinweis und Ihrer E-Mail-Adresse, bisherige Eingaben zum Kopieren | Der Status 429 soll laut RFC 6585 erklären, was passiert ist. |
| Versand gescheitert | Seite mit dem Hinweis, dass der Fehler bei Ihnen liegt, Eingaben zum Kopieren, Ihre E-Mail-Adresse | Sonst ginge die Anfrage verloren, ohne dass jemand es merkt. |
Das W3C rät, Fehler zu Beginn der Seite aufzulisten, vor dem Formular, und gerade bei serverseitiger Verarbeitung die Überschrift und den Titel der Seite mit dem Wort „Fehler“ zu ergänzen (W3C-Anleitung zu Formular-Meldungen (externe Website)). Die Antwort 429 Too Many Requests soll eine Erklärung enthalten und kann mit Retry-After nennen, wann ein neuer Versuch möglich ist (RFC 6585, Abschnitt 4 (externe Website)).
Erledigt, wenn Sie jeden Fall einmal ausgelöst haben und keine Eingabe verloren ging.
Wie prüfen Sie Ihr eigenes Formular?
Öffnen Sie die Entwicklerwerkzeuge Ihres Browsers und senden Sie eine Testanfrage. Unter Network sehen Sie, welche Dienste die Seite lädt, unter Application die Cookies. Danach schalten Sie JavaScript aus und senden noch einmal. So sehen Sie selbst, ob das Formular fremde Dienste lädt und ohne Skript funktioniert.
- Fremde Adressen. Laden Sie die Seite mit geöffnetem Bereich Network neu und sortieren Sie nach Domain. Alles außer Ihrer eigenen Domain ist ein fremder Dienst.
- Cookies. Öffnen Sie unter Application (in Firefox: Web-Speicher) den Eintrag Cookies. Bei einem Formular ohne Cookies steht dort auch nach dem Absenden nichts.
- Ziel des Formulars. Suchen Sie im Quelltext nach
action. Zeigt die Adresse auf eine fremde Domain, gehen die Eingaben dorthin. - JavaScript aus. Deaktivieren Sie JavaScript in den Einstellungen der Entwicklerwerkzeuge und senden Sie das Formular ab. Es muss ankommen.
- Fehler. Senden Sie ein leeres Pflichtfeld. Die Meldung muss als Text erscheinen, und die übrigen Eingaben bleiben stehen.
Dieselben Prüfungen können Sie an unserer Kontaktseite durchführen. Punkt 4 löst dort eine echte Anfrage aus, wenn Sie bis zum Ende absenden. Bitte senden Sie deshalb nur ein echtes Anliegen ab.
Das Formular besteht alle fünf Prüfungen, und es kommen trotzdem keine Anfragen? Dann prüfen Sie Zustellung, Auffindbarkeit, Angebot, Vertrauen und Kontaktweg: Warum bringt meine Website keine Anfragen?Erledigt, wenn Sie alle fünf Prüfungen protokolliert haben, auch auf dem Smartphone.
Was gilt in Deutschland und der EU?
Ein Formular ohne Tracking verarbeitet trotzdem personenbezogene Daten. Beschreiben Sie Felder, Zweck, Empfänger und Speicherdauer in der Datenschutzerklärung, und schließen Sie mit Hoster und E-Mail-Anbieter einen Vertrag über die Verarbeitung in Ihrem Auftrag. Was das rechtlich für Sie heißt, klärt Ihre Anwältin oder Datenschutzberatung; hier steht nur praktischer Rat.
- Nur abfragen, was Sie brauchen. Jedes Feld sollte einen Zweck haben, freiwillige Felder sind als freiwillig erkennbar.
- Empfänger kennen. Listen Sie auf, wer die Anfragen technisch berührt: Hoster, Serverfunktion und E-Mail-Anbieter. Halten Sie fest, wo die Serverfunktion läuft.
- Speicherdauer festlegen. Löschen Sie Anfragen ohne Auftrag nach einer festen Frist. Fragen Sie Ihre Steuerberatung, was Sie aufbewahren müssen.
- Captcha-Dienste gesondert ansehen. Nutzen Sie doch einen, prüfen Sie vorher, welche Daten er erhebt, wohin sie gehen und ob er vor dem Absenden eine Einwilligung braucht.
Wie wir es für unser Formular beschreiben, steht im Abschnitt zum Kontaktformular in unserer Datenschutzerklärung. Sie ist ein Beispiel und kein Muster für Ihren Fall.
Erledigt, wenn Ihre Datenschutzerklärung Felder, Empfänger und Speicherdauer des Formulars nennt und jemand Fachkundiges sie geprüft hat.
Aus der Praxis: So ist das Formular von datafalke.de gebaut
Das Formular auf unserer Kontaktseite läuft seit dem 07.11.2026 online, ohne JavaScript und ohne Dienste anderer Anbieter. Der erste Schritt ist Teil der statischen Seite. Den zweiten gibt ein Programm auf den Servern unseres Hosters aus, und es prüft die Anfrage beim Absenden. Die genauen Grenzen und Namen nennen wir hier nicht, weil sie Angreifern helfen würden.
| Baustein | So ist es bei uns | Preis oder Grenze |
|---|---|---|
| Auslieferung | Fertiges HTML, kein Cookie, keine Inhalte anderer Anbieter; die Kopfzeile Content-Security-Policy verbietet Skripte | Jede Änderung heißt neu bauen und hochladen |
| Zwei Schritte | Anliegen wählen auf der statischen Seite, Kontaktdaten im Schritt vom Server, dort mit signierter Zeitmarke | Ein Klick mehr als bei einem einteiligen Formular |
| Schutz vor Missbrauch | Für Menschen unsichtbares Feld, signierte Zeitmarke, begrenzte Zahl von Anfragen je Netzadresse | Kein Schutz gegen Bots, die den Ablauf gezielt nachbauen |
| Zählung | Prüfwert aus IP-Adresse und täglich wechselndem Schlüssel, abgelaufen nach spätestens einem Tag; die IP-Adresse selbst speichern wir dafür nicht | Unser Hoster speichert Verbindungsdaten trotzdem drei Tage in seinen Protokollen |
| Wo es läuft | Programm ausschließlich auf Servern in der EU, Postfach bei STRATO in Deutschland | Wir pflegen das Programm selbst |
| Bestätigung | Keine automatische Bestätigung und keine Kopie an Absender, persönliche Antwort | Absender sehen nur die Danke-Seite als Eingangsbestätigung |
| Herkunft | Freiwillige Frage, wie Sie uns gefunden haben, ausgewertet nur in Summen | Nicht jede Anfrage beantwortet sie |
Sendet jemand eine schon angekommene Anfrage im Browser noch einmal, geht in der Regel keine zweite Mail hinaus. Das Programm führt dann direkt zur Danke-Seite. Wie die Seite insgesamt gebaut ist, steht im Technik-Abschnitt des Kolophons.
Zahlen zu abgewehrtem Spam nennen wir noch keine, weil das Formular erst seit wenigen Tagen online ist. Sollte Spam trotz dieser Prüfungen überhandnehmen, ist als letzte Stufe ein Rechenrätsel im Browser vorgesehen (ALTCHA). Dann liefe auf der Kontaktseite doch JavaScript, und unsere Aussage dazu müsste sich ändern.
Wie wir Websites bauen, steht auf der Seite Website erstellen lassen.
Häufige Fragen
Reicht ein verstecktes Feld allein gegen Spam?
Für einfache Bots oft ja, gegen Bots, die für Ihr Formular geschrieben wurden, nicht. Das ist unsere Einschätzung. Kombinieren Sie es deshalb mit einer signierten Zeitmarke und einer Zählung je Netzadresse.
Geht das auch mit WordPress?
Die Prüfungen auf dem Server lassen sich auch dort umsetzen. Prüfen Sie jedes Formular-Plugin mit den Schritten oben, denn Plugins können Skripte oder Schriften laden. Ob eine statische Website oder WordPress für Sie passt, zeigt unser Vergleich statische Website oder WordPress.