Digitaler Empfang

Was im Hintergrund passiert – und warum

Ein Kontaktformular sieht auf den ersten Blick einfach aus. Damit es zuverlässig zustellt, keine Angriffsfläche bietet und nicht in Spam-Fluten untergeht, steckt dahinter aber eine Reihe bewusster technischer Entscheidungen. Hier die Erklärung zu jedem einzelnen Punkt.

Formularfelder individuell auf den Betrieb abgestimmt

Statt der üblichen drei Felder „Name, E-Mail, Nachricht“ bekommt jedes Formular die Felder, die zum jeweiligen Anliegen passen – etwa Terminwunsch bei einer Praxis, Rezeptanfrage bei einer Apotheke oder gewünschte Leistung bei einem Kostenvoranschlag. Das spart beiden Seiten Rückfragen: Der Betrieb bekommt sofort die Information, die er für eine Antwort braucht, statt erst nachfragen zu müssen.

Datenschutz-Checkbox mit Hinweis

Vor dem Absenden muss aktiv bestätigt werden, dass die Datenschutzerklärung zur Kenntnis genommen wurde. Das ist kein reiner Formalismus: Die DSGVO verlangt, dass Besucher informiert werden, was mit ihren Daten passiert, bevor sie sie abschicken – eine bereits angehakte oder fehlende Checkbox würde das nicht erfüllen.

Spam-Schutz ohne CAPTCHA (Honeypot + Zeitprüfung)

Ein Honeypot ist ein zusätzliches Formularfeld, das per CSS für Menschen unsichtbar gemacht wird, im HTML-Code aber vorhanden ist. Automatisierte Spam-Programme lesen den Code, nicht das Aussehen der Seite – sie füllen dieses Feld aus, weil sie es sehen. Menschen füllen es nie aus, weil sie es nie zu Gesicht bekommen. Ist das Feld beim Absenden ausgefüllt, wird die Nachricht still verworfen. Die Zeitprüfung ergänzt das: Ein Bot lädt die Seite und sendet das Formular oft in Sekundenbruchteilen ab, ein Mensch braucht spürbar länger zum Lesen und Ausfüllen. Wird ein Formular unrealistisch schnell abgeschickt, gilt das als Spam-Indiz.

Der Grund, warum hier bewusst kein CAPTCHA (z. B. Google reCAPTCHA) eingesetzt wird: Ein CAPTCHA lädt externes JavaScript von einem Drittanbieter nach, überträgt dabei Nutzerdaten an dessen Server und erschwert Menschen mit Sehschwäche oder älteren Geräten die Bedienung unnötig. Honeypot und Zeitprüfung erreichen einen vergleichbaren Schutz, ohne Drittanbieter einzubinden und ohne dass Besucher irgendetwas zusätzlich tun müssen.

CSRF-Schutz und Rate Limiting

CSRF steht für Cross-Site Request Forgery – einen Angriff, bei dem eine fremde, bösartige Webseite versucht, im Hintergrund unbemerkt Formulare auf einer anderen Seite in Ihrem Namen abzuschicken. Dagegen bekommt jedes Formular ein einmaliges, unsichtbares Sicherheits-Token, das nur beim Laden der echten Seite ausgestellt wird. Ohne gültiges Token wird die Anfrage abgelehnt – Formulardaten können also nachweislich nur von der eigenen Website selbst kommen.

Rate Limiting begrenzt, wie viele Nachrichten in einem kurzen Zeitraum von derselben Quelle gesendet werden können. Das verhindert, dass ein Angreifer das Formular in Dauerschleife befeuert, das Postfach flutet oder – im schlimmsten Fall – den SMTP-Versand so missbraucht, dass die Absender-Adresse als Spam-Quelle eingestuft und gesperrt wird.

Eigenes Dashboard zur Verwaltung der SMTP-Zugangsdaten

SMTP ist das technische Protokoll, über das E-Mails tatsächlich verschickt werden – im geschützten Verwaltungsbereich werden Host, Port, Benutzername und Passwort des E-Mail-Versands hinterlegt, inklusive Testversand. Ändert sich später der Hoster oder das Postfach, kann das selbst angepasst werden, ohne dass jemand Code bearbeiten muss.

SMTP-Zugangsdaten werden nicht im Frontend gespeichert

Die hinterlegten Zugangsdaten liegen ausschließlich serverseitig in einer geschützten Konfiguration – sie werden zu keinem Zeitpunkt an den Browser ausgeliefert. Wer sich die Seitenquelle oder den Netzwerkverkehr im Browser ansieht, kann sie also grundsätzlich nicht einsehen.

Keine Datenbank, keine Plugin-Pflege

Das Formular verschickt Nachrichten direkt per E-Mail, statt sie in einer eigenen Datenbank zwischenzuspeichern, und läuft ohne Plugins von Drittanbietern, wie sie etwa in WordPress üblich sind. Das reduziert die Angriffsfläche spürbar: keine Datenbank, die per SQL-Injection angegriffen werden könnte, keine Plugin-Version, die veraltet und damit verwundbar werden kann.

Funktioniert auf jedem normalen PHP-Hosting

Es wird keine besondere Serverumgebung benötigt – normales PHP-Hosting, wie es praktisch jeder Anbieter bereitstellt, reicht aus. Das bedeutet keine Abhängigkeit von einem bestimmten Hoster oder Zusatzdienst und jederzeit die Möglichkeit, zu einem anderen Anbieter zu wechseln.