Website-Formulare prüfen: Labels, Eingabetypen, HTTPS und CSRF

Kontaktformulare, Registrierungen, Logins, Checkouts und Suchfelder sind die Stellen, an denen Ihre Website Besucher zu einer Handlung auffordert. Ein Formular, das verwirrt, sich auf dem Smartphone schlecht ausfüllen lässt oder unsicher ist, kostet Sie Anfragen und Vertrauen – und Formularprobleme fallen selten auf, bevor sich jemand beschwert, denn wer aufgibt, sagt Ihnen das nicht.

Die meisten Formularprobleme sind im HTML sichtbar und lassen sich daher prüfen, ohne etwas auszufüllen. Darauf sollten Sie achten.

Usability und Barrierefreiheit

Jedes Feld braucht ein Label

Jedes Eingabefeld braucht ein <label>, das über for und id mit ihm verknüpft ist (oder es umschließt). Screenreader lesen das Label vor, und ein Klick darauf setzt den Fokus ins Feld. Ein Platzhalter ist kein Label: Er verschwindet, sobald jemand tippt, ist oft kontrastarm und wird nicht zuverlässig vorgelesen. Lässt ein Design ein sichtbares Label wirklich nicht zu, ist aria-label die Ausweichlösung – sichtbare Labels helfen aber allen. Unser Leitfaden zur Barrierefreiheit geht ausführlicher auf Labels ein.

Den richtigen Eingabetyp verwenden

type="email", type="tel" und type="url" blenden auf Smartphones die passende Tastatur ein und bringen eine einfache Validierung durch den Browser mit. Ein Telefonfeld mit type="text" zwingt mobile Besucher, die Ziffern erst zu suchen. Vorsicht bei type="number": Der Typ ist für Mengenangaben gedacht, nicht für Telefonnummern, Kartennummern oder Postleitzahlen.

Autocomplete-Hinweise ergänzen

Das Attribut autocomplete teilt Browsern und Passwortmanagern mit, wofür ein Feld gedacht ist: name, email, tel, street-address, postal-code, cc-number, current-password, new-password, one-time-code. Damit füllen Besucher ein Formular mit einem Fingertipp aus, und für Felder, die Angaben zur Person erfassen, ist es eine Anforderung der WCAG 2.1 (Erfolgskriterium 1.3.5). Setzen Sie bei Passwortfeldern kein autocomplete="off": Das drängt Menschen zu schwächeren, mehrfach verwendeten Passwörtern.

Ein echter Absende-Button und hilfreiche Validierung

Verwenden Sie einen <button type="submit">, damit das Formular mit der Eingabetaste und ohne eigenes JavaScript funktioniert. Kennzeichnen Sie Pflichtfelder mit dem Attribut required und weisen Sie im Label darauf hin, und zeigen Sie Fehlermeldungen direkt am Feld und in verständlichen Worten an. novalidate schaltet die eingebauten Prüfungen des Browsers ab; das ist nur in Ordnung, wenn Sie sie durch eigene ersetzen.

Sicherheit

• HTTPS für die Seite und die Action. Ein Passwortfeld auf einer HTTP-Seite oder ein Formular, dessen action auf eine http://-URL zeigt, überträgt die Eingaben im Klartext. Sowohl die Seite als auch die Action müssen HTTPS verwenden.
• Niemals GET für Passwörter. Mit method="get" landen die Formularwerte in der URL – und von dort im Browserverlauf, in Server-Logs und in Referrer-Headern. Verwenden Sie für alles Sensible method="post".
• CSRF-Schutz. Formulare, die etwas verändern (anmelden, ein Konto aktualisieren, eine Bestellung aufgeben), sollten vor Cross-Site Request Forgery geschützt sein – in der Regel durch ein geheimes Token in einem versteckten Feld, das der Server prüft, ergänzt durch SameSite-Cookies. Siehe Cookie-Sicherheit prüfen.
• Wissen, wohin die Daten gehen. Ein Formular, das an eine andere Domain sendet, etwa an einen Newsletter- oder CRM-Anbieter, kann durchaus gewollt sein – stellen Sie aber sicher, dass es beabsichtigt ist und von Ihrer Datenschutzerklärung abgedeckt wird.
• Auf dem Server validieren. Die Validierung im Browser ist eine Annehmlichkeit für ehrliche Besucher; umgehen kann sie jeder. Der Server muss jeden Wert erneut prüfen.

Wie Rudra Formulare prüft – ohne sie abzusenden

Der kostenlose Broken-Link-Checker und das Website-Audit laden Ihre Seite in einem echten Browser und untersuchen bis zu 10 Formulare darauf. Unter Angabe der betroffenen Formular- und Feldnamen melden sie:

• Passwortfelder auf einer HTTP-Seite, Formulare, die an http:// senden, und Passwortformulare mit GET (jeweils 10 Punkte Abzug);
• Felder, deren einzige Beschriftung ein Platzhalter ist (3 Punkte);
• Felder ohne zugängliches Label, Eingabetypen, die nicht zum Feld passen (ein E-Mail-Feld mit type="text"), fehlende Autocomplete-Hinweise, autocomplete="off" bei Passwörtern, Formulare, die an einen anderen Host senden, Formulare ohne Absende-Button, Pflichtfelder für E-Mail oder Telefon ohne Einschränkungen sowie novalidate – alles rein informativ;
• POST-Formulare ohne sichtbares Token nach Art eines CSRF-Tokens – mit geringer Sicherheit, weil das Token per JavaScript ergänzt werden oder der Server das Formular auf andere Weise schützen kann.

Außerdem wird der Browser einmalig gefragt, ob er das leere Absenden von Pflichtfeldern blockieren würde – indem der Validierungsstatus jedes Feldes ausgelesen wird, ohne etwas zu fokussieren oder auszufüllen und ohne die eigenen Validierungs-Handler der Website auszulösen.

Warum wir Formulare niemals absenden

Ein Formular abzusenden hat reale Folgen: Eine E-Mail landet in einem Postfach, ein Konto wird angelegt, eine Bestellung oder ein Support-Ticket entsteht, ein Rate Limit oder ein Betrugsfilter schlägt an. Ein automatisiertes Tool kann nicht wissen, welche Formulare sich gefahrlos absenden lassen – unseres sendet deshalb kein einziges ab. Formulare werden niemals abgesendet, angeklickt, fokussiert oder ausgefüllt, und Berichte enthalten ausschließlich Feldnamen und Labels – niemals Werte.

Der Preis dafür: Manches lässt sich nur testen, indem man ein Formular absendet, und das bleibt Ihnen überlassen – ob die Übermittlung ankommt, wie Bestätigungs- und Fehlermeldungen aussehen, ob der Server fehlerhafte oder von fremden Websites stammende Eingaben zurückweist und ob der Spamschutz funktioniert.

Ein manueller Test für jedes Formular

1. Füllen Sie es auf einem Smartphone aus und prüfen Sie, ob jedes Feld die richtige Tastatur einblendet und sinnvoll automatisch ausgefüllt wird.
2. Füllen Sie es ausschließlich mit der Tastatur aus und danach mit einem Screenreader wie NVDA oder VoiceOver.
3. Senden Sie es leer und mit einer falschen E-Mail-Adresse ab und lesen Sie die Fehlermeldungen.
4. Senden Sie es korrekt ab und vergewissern Sie sich, dass die Nachricht dort ankommt, wo sie ankommen soll.
5. Lassen Sie sich bei Logins und Kontoformularen von einem Entwickler den CSRF-Schutz und die serverseitige Validierung bestätigen.