Macht clientseitige (JavaScript-)Eingabevalidierung deine Anwendung sicher?
Kurzantwort
Nein. Clientseitige Validierung ist reiner UX-Komfort — ein Angreifer kann JavaScript abschalten, die Anfrage im Browser oder in Burp bearbeiten oder die API direkt mit curl aufrufen und sie so vollständig umgehen. Sicherheitsprüfungen (Validierung, Autorisierung, Bereinigung) müssen auf dem Server erzwungen werden, dem einzigen Ort, den du kontrollierst. Der Irrtum ist, den Browser für eine Vertrauensgrenze zu halten; das ist er nicht, denn der Client läuft auf dem Rechner des Angreifers. Clientprüfungen sind toll für schnelles Feedback, nie für Sicherheit.
Diese Frage trennt Entwickler, die verstehen, wo Vertrauen liegt, von jenen, die annehmen, der Browser setze ihre Regeln durch. Es ist einer der häufigsten — und gefährlichsten — Anfängerirrtümer in der Web-Sicherheit.
Warum die populäre Antwort falsch ist
Es wirkt intuitiv: Wenn das Formular schlechte Eingaben ablehnt, erreichen sie nie den Server. Doch der Browser steht nicht unter deiner Kontrolle — er läuft auf dem Rechner des Angreifers. JavaScript lässt sich abschalten, Breakpoints setzen, das DOM bearbeiten und maxlength-Attribute in einer Sekunde löschen. Grundlegender noch: Der Browser ist optional. Ein Angreifer kann ihn völlig überspringen und eine rohe HTTP-Anfrage mit curl, Postman oder einem Intercepting-Proxy wie Burp Suite senden. Keine deiner Frontend-Prüfungen läuft dann ab. JavaScript zu verschleiern oder zu minifizieren ändert nichts — die Anfrage reist weiter übers Netz, wo sie umgeschrieben werden kann, und das Abschalten von Entwicklertools oder Rechtsklick-Menü ist trivial umgehbar.
Die Vertrauensgrenze
Sicherheit muss an einer Vertrauensgrenze durchgesetzt werden, die du wirklich kontrollierst: dem Server. Alles, was vom Client kommt, ist per Definition nicht vertrauenswürdig. Daher gehören Validierung, Autorisierung und Bereinigung auf den Server. Clientseitige Validierung bleibt wertvoll — sie liefert sofortiges Feedback, spart Roundtrips und verbessert die UX — aber sie ist ein Usability-Feature, kein Sicherheitsmechanismus.
Was du stattdessen tun solltest
Spiegle jede Client-Regel auf dem Server und ergänze die Prüfungen, die der Client nicht garantieren kann: Typ- und Bereichsvalidierung, Allowlist-Filterung, Längenbegrenzungen, Autorisierung (gehört dieser Datensatz diesem Nutzer?) und kontextabhängiges Output-Encoding gegen XSS. Frameworks und das OWASP ASVS fassen das zusammen als „traue dem Client nie”. Gutes Denkmodell: Nimm an, deine API sei öffentlich und werde direkt von Angreifern aufgerufen, und frage dann, ob jeder Endpunkt weiterhin sicher ist. Falls ja, sitzt deine Validierung am richtigen Ort.
Wahrscheinliche Anschlussfragen
- Wenn Client-Validierung der UX dient, was soll der Server mit denselben Regeln tun?
- Wie umgeht man in der Praxis ein 'maxlength'-Feld und eine E-Mail-Regex-Prüfung?
- Wo steht Eingabevalidierung im Verhältnis zu Output-Encoding und Autorisierung?