Die Entscheidung, wo Daten validiert werden, ist nicht nur eine technische Frage. Sie beeinflusst das Nutzererlebnis, die Integrität des Geschäfts und die Betriebskosten einer Anwendung. Eine Fehlermeldung, die sofort erscheint, kann beim Ausfüllen eines Formulars helfen, garantiert aber nicht, dass eine Aktion gültig ist. Und wenn sämtliche Prüfungen auf den Server verlagert werden, sind Daten zwar geschützt, unnötige Wartezeiten und Frustration aber nicht unbedingt vermieden.
Am sinnvollsten ist es, jede Regel der Ebene zuzuordnen, die sie mit den passenden Informationen und der nötigen Entscheidungsbefugnis anwenden kann. Die Oberfläche gibt Orientierung, der Server schützt Geschäftsregeln und asynchrone Prozesse erledigen langsame oder von externen Diensten abhängige Prüfungen. In vielen Abläufen arbeiten alle drei Ebenen zusammen.
Warum eine einzelne Ebene oft nicht ausreicht
Eine Validierung ausschließlich in der Oberfläche kann schnell und verständlich sein. Sie lässt sich jedoch umgehen, indem jemand eine API direkt aufruft, eine Anfrage manipuliert oder einen anderen Client verwendet. Deshalb darf sie niemals die einzige Schutzmaßnahme für eine Regel sein, die Daten oder Geschäftsentscheidungen schützt.
Am anderen Ende des Spektrums zwingt eine Validierung erst nach dem Absenden Menschen dazu, auf die Rückmeldung zu warten, obwohl es um einfache Fehler geht: ein leeres Pflichtfeld oder eine E-Mail-Adresse im falschen Format. Manche Prüfungen dauern außerdem länger als eine gewöhnliche Anfrage oder hängen von Systemen ab, die vorübergehend nicht verfügbar sein können.
Die hilfreiche Frage lautet nicht: „Welche Ebene validiert die Daten?“, sondern „Welche Ebene bietet für die jeweilige Regel die beste Kombination aus Schnelligkeit, Entscheidungsbefugnis und Kontext?“ So kann ein Längenlimit im Browser angezeigt und anschließend auf dem Server erneut geprüft werden. Die Oberfläche erleichtert die Eingabe; ob der Wert akzeptiert oder abgelehnt wird, entscheidet weiterhin der Server.
Oberfläche: sofortige Rückmeldung, aber keine letzte Instanz
Die Validierung in der Oberfläche eignet sich, um Probleme früh zu erkennen, die sich ohne externe Informationen erklären lassen: leere Felder, Zeichenbegrenzungen, grundlegende Formate oder einfache Kombinationen. So gibt es weniger erfolglose Versuche, und es wird klar, was vor dem Absenden noch fehlt.
Eine nützliche Meldung erscheint direkt am Feld oder in einer barrierefrei zugänglichen Zusammenfassung. Sie erklärt das Problem und schlägt eine Korrektur vor. Vermeiden Sie voreilige Fehlermeldungen, die den Eingabeprozess unterbrechen, obwohl jemand noch schreibt. Eine sinnvolle Praxis ist es, beim Verlassen des Feldes oder beim Absenden zu prüfen und die Meldung zu aktualisieren, sobald sich der Wert ändert.
Die Oberfläche kann auch bekannte Grenzen vorab anzeigen, etwa das erwartete Datumsformat. Eine Aktion darf jedoch nicht allein deshalb als gültig gelten, weil das Formular sie akzeptiert. Der Browser kann veraltet sein, der Client lässt sich verändern und die Anfrage kann über einen anderen Weg eintreffen.
- Nutzen Sie die Oberfläche für schnelle Rückmeldungen und einfache Regeln, die die Dateneingabe erleichtern.
- Verlassen Sie sich nicht allein darauf, wenn es um Autorisierung, Berechtigungen, endgültige Preise oder die Integrität gespeicherter Datensätze geht.
- Erklären Sie Einschränkungen klar und vermeiden Sie Meldungen, die vertrauliche Informationen offenlegen.
Server: maßgeblich für Geschäftsregeln
Der Server muss jede Bedingung erneut prüfen, deren Verletzung Daten verändern, unbefugten Zugriff ermöglichen oder zu einer falschen Entscheidung führen könnte. Dazu gehört zu kontrollieren, ob die Person die Aktion ausführen darf, ob die Werte zum erlaubten Kontext gehören und ob die vorgesehenen Statusübergänge zulässig sind.
Die Prüfung muss dort stattfinden, wo Daten akzeptiert oder geändert werden, und nicht nur auf einer bestimmten Bildschirmseite. Nutzen mehrere Anwendungen dieselbe API, stellt der Server eine gemeinsame Richtlinie bereit. Außerdem muss er mit konkurrierenden Änderungen umgehen können: Zwei Anfragen können gleichzeitig um eine Ressource konkurrieren oder denselben Datensatz ändern wollen.
Auch bei einer serverseitigen Validierung sind verständliche Fehlermeldungen wichtig. Soweit es sicher ist, sollte die Antwort zwischen fehlerhaften Daten, einer verletzten Geschäftsregel und fehlender Berechtigung unterscheiden. Interne Details, Abfragen, Stacktraces oder Informationen, die einen Angriff erleichtern könnten, sollten nicht zurückgegeben werden. Die OWASP-Empfehlungen zur Eingabevalidierung sind eine hilfreiche Orientierung, um eingehende Daten als nicht vertrauenswürdig zu behandeln.
Faustregel: Schützt das Ergebnis eine Entscheidung oder die Systemintegrität, hat der Server das letzte Wort – auch wenn die Oberfläche eine gleichartige Prüfung durchführt, um unnötige Hürden zu vermeiden.
Asynchrone Prozesse: externe Abhängigkeiten und verzögerte Ergebnisse
Manche Regeln lassen sich weder mit einer lokalen Prüfung noch mit einer einzigen schnellen Anfrage klären. Eine Adresse über einen externen Dienst zu überprüfen, eine Datei zu analysieren oder eine zeitaufwendige Prüfung abzuschließen, kann dazu führen, dass die eingereichte Anfrage zunächst den Status „ausstehend“ erhält.
Trennen Sie in solchen Fällen die Annahme der Anfrage vom endgültigen Ergebnis. Das System kann den Eingang bestätigen und mitteilen, dass die Prüfung noch läuft, ohne bereits zu behaupten, die Daten seien gültig. Nach Abschluss der Prüfung muss es den Status aktualisieren und das Ergebnis über einen für das Produkt geeigneten Weg mitteilen, etwa über eine Statusansicht oder eine Benachrichtigung.
Planen Sie auch den Fehlerfall: Was geschieht, wenn der externe Dienst nicht antwortet, ein uneindeutiges Ergebnis liefert oder nach einer Unterbrechung wieder verfügbar ist? Legen Sie Zeitlimits, angemessene Wiederholungsversuche sowie einen Weg für Überprüfung oder Wiederherstellung fest. Eine Zeitüberschreitung beweist nicht, dass die Daten ungültig sind. Sie kann bedeuten, dass die Prüfung nicht abgeschlossen werden konnte.
Kann das Ergebnis eintreffen, nachdem die Person die Seite verlassen hat, muss der Status weiterhin abrufbar sein. Verhindern Sie außerdem, dass eine verspätete Antwort eine neuere Änderung überschreibt: Ordnen Sie das Ergebnis der geprüften Anfrage oder Version zu.
Festlegen, wo eine Regel angewendet wird
Bewerten Sie jede Validierung anhand von vier Fragen: Wie teuer ist ein Fehler? Welche Informationen werden benötigt? Wie lange dauert es, bis das Ergebnis vorliegt? Und wer darf die Entscheidung treffen? So lassen sich Regeln unterscheiden, die in einem Formular oft miteinander vermischt sind.
- Nutzererlebnis: Ist eine Prüfung einfach und lässt sich der Fehler sofort beheben, zeigen Sie ihn in der Oberfläche an.
- Sicherheit und Integrität: Betrifft die Regel Berechtigungen, gespeicherte Daten oder eine finanzielle Entscheidung, wenden Sie sie auf dem Server an.
- Abhängigkeiten und Latenz: Sind externe Dienste oder eine längere Analyse erforderlich, zeigen Sie einen ausstehenden Status an und verarbeiten Sie das Ergebnis später.
- Fehlerkosten: Je größer die Folgen eines falschen Werts sind, desto mehr Kontrollen und Nachvollziehbarkeit sind erforderlich.
Eine Regel kann auf mehreren Ebenen geprüft werden, doch nicht jede Ebene muss sie gleich ausführlich behandeln. Die Oberfläche kann kontrollieren, ob ein Feld ausgefüllt ist; der Server prüft zusätzlich Kontext und Berechtigungen. Redundanz ist sinnvoll, wenn jede Prüfung einen klaren Zweck erfüllt.
Konsistenz sichern, ohne Regeln auseinanderlaufen zu lassen
Wer eine Regel mehrfach umsetzt, riskiert, dass sie auf einer Ebene geändert und auf einer anderen vergessen wird. Dann akzeptiert die Oberfläche möglicherweise einen Wert, den der Server ablehnt, oder blockiert einen gültigen Wert. Um solche Abweichungen zu verringern, sollten Geschäftsregeln eine eindeutig erkennbare maßgebliche Quelle haben und die Verträge zwischen Client und API klar sein.
Wenn es die Architektur erlaubt, können Schemas oder Validierungskomponenten zwischen Client und Server geteilt werden. Dadurch wird der Client jedoch nicht zur maßgeblichen Instanz: Der Server muss die Prüfung an seiner eigenen Vertrauensgrenze ausführen. Ist eine gemeinsame Implementierung nicht möglich, dokumentieren Sie Kriterien, Grenzfälle und erwartete Antworten und ergänzen Sie Tests für beide Seiten.
Achten Sie besonders auf Regeln, die sich mit der Zeit ändern oder von Nutzenden, Region, Kontostatus oder Ressourcenverfügbarkeit abhängen. Verankern Sie keine Entscheidungen als feste Werte in der Oberfläche, wenn der Server sie aktualisieren kann. Werden dem Client informative Einschränkungen übermittelt, sollten sie als Orientierung gelten, die möglicherweise veraltet ist.
Fehlermeldungen, die den nächsten Schritt zeigen
Eine hilfreiche Fehlermeldung benennt den betroffenen Wert, erklärt den Grund ohne Fachjargon und schlägt einen nächsten Schritt vor. Lässt sich der Fehler vor dem Absenden korrigieren, sollte die Meldung dem Feld zugeordnet sein. Läuft die Aktion bereits, erklären Sie den allgemeinen Status und wie sich der Vorgang prüfen oder wiederholen lässt. Damit Wiederholungen keine Duplikate erzeugen, muss das Design berücksichtigen, was passiert, wenn die erste Anfrage erfolgreich war, ihre Antwort den Client aber nicht erreicht hat.
Verwenden Sie keine Fehlermeldung an einem Feld für einen Zustand, der vom Gesamtprozess abhängt. Ist eine Ressource beispielsweise nicht mehr verfügbar, sollte die Änderung erklärt und sollten Alternativen angeboten werden. Es reicht nicht, das Format des Feldes als falsch zu markieren. Wenn der genaue Grund aus Sicherheitsgründen nicht offengelegt werden darf, geben Sie eine neutrale Erklärung und einen Weg an, den Vorgang fortzusetzen.
Checkliste vor dem Start
- Listen Sie alle Regeln auf und ordnen Sie sie Format, Geschäftslogik, Autorisierung oder externen Abhängigkeiten zu.
- Stellen Sie sicher, dass jede kritische Regel auf dem Server geprüft wird, bevor eine Änderung angenommen wird.
- Prüfen Sie, ob Meldungen in der Oberfläche rechtzeitig, barrierefrei und umsetzbar sind.
- Legen Sie den Umgang mit ausstehenden Status, vorübergehenden Fehlern, Wiederholungen und verspäteten Antworten fest.
- Testen Sie direkte API-Anfragen, Grenzwerte, Berechtigungen und konkurrierende Änderungen.
- Kontrollieren Sie, dass Fehlermeldungen keine internen Daten offenlegen und den nächsten Schritt nennen.
- Bestimmen Sie, wer gemeinsame Regeln aktualisiert, wenn sich das Produkt ändert.
Das beste Design validiert nicht alles überall und wartet auch nicht immer auf den Server. Kombinieren Sie frühzeitige Rückmeldungen mit einer klaren Entscheidungsinstanz und einem geregelten Umgang mit verzögerten Prüfungen. So wird die Anwendung verständlicher für ihre Nutzenden und widerstandsfähiger gegenüber ungültigen Daten, veränderten Kontexten und Ausfällen abhängiger Dienste.