Eingabevalidierung in mobilen Apps — Grundlagen, Prüfmethoden und Umsetzung

Was ist Eingabevalidierung?

Eingabevalidierung ist die Prüfung, ob die Daten, die von einem Benutzer, einem externen Dienst oder einer anderen Komponente in die Anwendung gelangen, den erwarteten Kriterien entsprechen. Zu diesen Kriterien gehören der Datentyp (String, Zahl, Datum), das Format (E-Mail, URL, Telefon), der Wertebereich (Alter von 18 bis 120), die Länge (Passwort von 8 bis 128 Zeichen) und die zulässigen Zeichen (nur lateinische Buchstaben, Ziffern, Bindestrich). Ohne Validierung kann die Anwendung Daten verarbeiten, die Laufzeitfehler, Datenbeschädigung oder Sicherheitslücken verursachen.

Warum ist Validierung ein kritisches Sicherheitselement?

Das Fehlen der Eingabevalidierung ist die Grundursache von Schwachstellen wie SQL Injection, XSS, Command Injection, Path Traversal und Buffer Overflow. Laut MITRE CWE (2025) steht CWE-20 (Improper Input Validation) an zweiter Stelle im Ranking der gefährlichsten Softwarefehler. Die Validierung ist die erste Verteidigungslinie im Sicherheitsmodell Defense in Depth: Sie schneidet fehlerhafte Daten ab, bevor sie andere Systemkomponenten erreichen.

Validierung vs Sanitisierung

Die Validierung weist Daten zurück, die die Kriterien nicht erfüllen. Die Sanitisierung (Reinigung) verändert die Daten, indem sie gefährliche Teile entfernt oder maskiert. Wenn beispielsweise HTML-Inhalte eingegeben werden, kann die Validierung die Textlänge prüfen und die Sanitisierung script-Tags über die Bibliothek HTML Purifier oder DOMPurify entfernen. Die Sanitisierung ersetzt die Validierung nicht: Sie arbeiten zusammen. Validierung ist eine „erlaubt/verboten“-Politik, Sanitisierung ist „vor der Verwendung gereinigt“.

Arten der Eingabevalidierung

Die Validierung wird nach der Tiefe der Prüfung klassifiziert. Die Formatvalidierung ist die einfachste und schnellste, die Geschäftsvalidierung die komplexeste und kontextabhängigste. Alle drei Ebenen müssen nacheinander angewendet werden: zuerst das Format, dann die Semantik, dann die Geschäftslogik. Das Überspringen einer Ebene kann zu fehlerhaftem Systemverhalten oder Schwachstellen führen.

Formatvalidierung

Prüfung von Datentyp, Größe, Format und zulässigen Zeichen. Sie wird über reguläre Ausdrücke, eingebaute Sprachtypen und Validierungsbibliotheken umgesetzt. Beispiele: Prüfung einer UUID (Format 8-4-4-4-12 hexadezimale Ziffern), Prüfung einer Telefonnummer (nur Ziffern, + am Anfang, 7 bis 15 Zeichen), Prüfung einer ganzen Zahl (Wert im Bereich Integer.MIN_VALUE — Integer.MAX_VALUE). Die Formatvalidierung ist die minimal erforderliche Ebene für jedes Eingabefeld.

Semantische Validierung

Prüfung der logischen Korrektheit der Daten im Kontext der Fachdomäne. Zum Beispiel: das Startdatum liegt nicht nach dem Enddatum, das Alter liegt in angemessenen Grenzen für das System, die Koordinaten liegen im Servicebereich. Die semantische Validierung erfordert Verständnis des Geschäftskontexts und kann nicht allein anhand des Formats durchgeführt werden. Beispiel: Das Feld „Anzahl der Tickets“ kann die Formatvalidierung bestehen (ganze Zahl, > 0), darf aber semantisch die Anzahl der verfügbaren Plätze nicht überschreiten.

Geschäftsvalidierung

Die komplexeste Ebene — Prüfung der Daten auf Übereinstimmung mit den Geschäftsregeln der Anwendung. Beispiele: Ein Benutzer kann den einzigen Administrator nicht löschen, die Bestellsumme überschreitet das Kreditlimit nicht, ein Artikel kann nur bestellt werden, wenn er auf Lager ist. Die Geschäftsvalidierung erfordert oft Datenbankabfragen oder externe Dienste und wird nach der Format- und Semantikprüfung durchgeführt. Fehler der Geschäftsvalidierung sind die häufigste Ursache für Unzufriedenheit der Benutzer.

Clientseitige und serverseitige Validierung

Die clientseitige Validierung (im Browser oder in der mobilen App) dient dem Benutzerkomfort: sofortiges Feedback ohne Daten an den Server zu senden. Die serverseitige Validierung ist jedoch die einzig zuverlässige, da Clientcode immer umgangen werden kann. Senden Sie Anfragen über Entwicklertools, Postman oder einen Proxy (Burp Suite) — und die clientseitige Validierung existiert nicht mehr. Laut PortSwigger Research (2025) verlassen sich mehr als 90% der getesteten Webanwendungen bei mindestens einem Feld ausschließlich auf die clientseitige Validierung.

Regel: Client für UX, Server für Sicherheit

Die clientseitige Validierung kann den Senden-Button deaktivieren, Fehler hervorheben und Hinweise anzeigen. Die serverseitige Validierung ist eine Pflichtprüfung jedes Parameters, auch wenn der Client ihn bereits geprüft hat. Die Doppelung der Validierung auf beiden Ebenen ist eine Standardpraxis. Der Server muss die Daten prüfen, als ob es den Client nicht gäbe. Das garantiert Schutz vor manipulierten Anfragen, automatisierten Angriffen und bösartigen Clients.

Umsetzung der clientseitigen Validierung

Im Web — HTML5-Attribute (required, pattern, min/max, type="email") und JavaScript. In mobilen Apps — native Validatoren für Textfelder (InputFilter in Android, textField(:shouldChangeCharactersIn:) in iOS). React Hook Form und Formik für React, Vuelidate für Vue, Angular Reactive Forms — beliebte Bibliotheken für die clientseitige Validierung. Sie alle unterstützen benutzerdefinierte Regeln und asynchrone Validierung (Prüfung der Eindeutigkeit des Logins auf dem Server).

// Beispiel für serverseitige Validierung mit Express und Joi
const Joi = require('joi');

const userSchema = Joi.object({
    email: Joi.string()
        .email()
        .required()
        .max(255),
    age: Joi.number()
        .integer()
        .min(18)
        .max(120)
        .required(),
    password: Joi.string()
        .pattern(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,128}$/)
        .required()
});

app.post('/api/users', async (req, res) => {
    const { error, value } = userSchema.validate(req.body);
    if (error) {
        return res.status(400).json({
            error: error.details[0].message
        });
    }
    // value — bereits geprüfte und sichere Daten
    const user = await User.create(value);
    res.status(201).json(user);
});

Validierung in mobilen Apps

Mobile Apps stellen besondere Anforderungen an die Datenvalidierung. Der Bildschirm ist kleiner — Fehler sollten prägnant sein, die Tastatur kontextbezogen (numerisch für Zahleneingabe) und die Prüfung asynchron, um die Benutzeroberfläche nicht zu blockieren. Native Plattformen bieten integrierte Validierungsmechanismen, die standardmäßig verwendet werden sollten. Die Material Design Guidelines für Android und die Human Interface Guidelines für iOS enthalten detaillierte Empfehlungen zur Anzeige von Validierungsfehlern.

Validierung auf Android (Jetpack Compose)

Jetpack Compose bietet einen deklarativen Ansatz zur Validierung über State-Management. Jedes Eingabefeld ist an einen Zustand (MutableState) gebunden, und der Fehler wird auf Grundlage des aktuellen Werts berechnet. Die Bibliothek Compose Validator vereinfacht das Erstellen von Regeln: required, email, min/max length, pattern. Die Validierung wird bei Änderung des Texts (onValueChange) oder beim Versuch, das Formular zu senden, ausgelöst. Es wird empfohlen, den Fehler erst nach dem ersten Senden oder nachdem der Benutzer mit der Eingabe fertig ist, anzuzeigen (Debounce 300-500ms).

Validierung auf iOS (SwiftUI)

SwiftUI hat keinen eingebauten Mechanismus zur Formularvalidierung, lässt sich aber über Combine und Property Wrapper leicht umsetzen. Verwenden Sie @State für den Feldwert und eine berechnete Eigenschaft für den Fehler. Das Framework ValidatedPropertyKit bietet fertige Dekoratoren: @Validated().email(), @Validated().range(18...120). iOS-Empfehlung — verwenden Sie Tastaturtypen (UIKeyboardType.emailAddress, .numberPad) und automatische Großschreibung, um die Anzahl der Fehler auf Eingabeebene zu reduzieren.

Validierung auf Flutter

Flutter bietet die Klassen Form und TextFormField mit integrierter Validierung über einen Validator-Callback. Jedes Feld gibt einen Fehler als String oder null zurück, wenn die Daten korrekt sind. FormState.validate() startet die Prüfung aller Formularfelder. Das Paket reactive_forms für komplexe Fälle: benutzerdefinierte Validatoren, asynchrone Prüfung, dynamische Regeln. Flutter Web und die mobile Version verwenden dieselbe API, was die Wartung vereinfacht.

// Beispiel für Formularvalidierung in Flutter
Form(
    key: _formKey,
    child: Column(
        children: [
            TextFormField(
                decoration: InputDecoration(labelText: 'Email'),
                validator: (value) {
                    if (value == null || value.isEmpty) {
                        return 'Email is required';
                    }
                    if (!RegExp(r'^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$')
                            .hasMatch(value)) {
                        return 'Enter a valid email';
                    }
                    return null;
                },
            ),
            ElevatedButton(
                onPressed: () {
                    if (_formKey.currentState!.validate()) {
                        // Gültige Daten verarbeiten
                    }
                },
                child: Text('Senden'),
            ),
        ],
    ),
)

Validierungstechniken und -werkzeuge

Moderne Frameworks bieten eingebaute Validatoren, die 80% der Anforderungen abdecken. Die restlichen 20% erfordern benutzerdefinierte Regeln, reguläre Ausdrücke oder die Kombination vorhandener Regeln. Das wichtigste Prinzip: Die Validierung sollte deklarativ sein, damit sie leicht gelesen, getestet und gewartet werden kann. Vermeiden Sie über Controller und Screens verteilte Validierungslogik — lagern Sie sie in separate Klassen oder Schemata aus.

White-list vs Black-list Ansätze

White-list (Whitelist) — Sie legen fest, welche Daten erlaubt sind, alles andere wird abgelehnt. Black-list (Blacklist) — Sie legen fest, welche Daten verboten sind, alles andere wird durchgelassen. Die Whitelist ist immer zuverlässiger: Sie wissen genau, welche Daten durchkommen. Die Blacklist erfordert, alle möglichen Angriffe vorherzusehen, was unmöglich ist. Beispiel: Bei der Altersprüfung verwenden Sie eine Whitelist (nur Zahlen von 18 bis 120) statt einer Blacklist (verbiete „0“, „-1“, „999999“).

Reguläre Ausdrücke — Macht und Gefahr

Reguläre Ausdrücke sind ein effektives Werkzeug für die Formatvalidierung, können aber eine Quelle von ReDoS-Angriffen (Regular Expression Denial of Service) sein. Einige Muster (zum Beispiel (a+)+b) führen bei langen Zeichenketten zu katastrophalem Backtracking und belasten die Server-CPU vollständig. Verwenden Sie bewährte Regex-Bibliotheken und begrenzen Sie die Länge der Zeichenkette, bevor Sie einen regulären Ausdruck anwenden. Für komplexe Fälle (E-Mail, URL) verwenden Sie die eingebauten Parser der Sprachen statt selbstgebauter Regex.

Typische Fehler bei der Validierung

Auch erfahrene Entwickler machen Fehler bei der Implementierung der Validierung. Die häufigsten: Validierung nur auf dem Client, zu strenge Regeln (Passwort „Must contain uppercase, lowercase, digit, special char, >= 12 chars, must not repeat characters“), nichtssagende Fehlermeldungen ("Error: invalid input") und das Ignorieren von Randfällen (Leerzeichen am Anfang/Ende, Unicode-Zeichen, leere Zeichenketten). Jeder dieser Fehler verschlechtert die UX und kann die Formularkonversion senken.

• Nur clientseitige Validierung — der gefährlichste Fehler: jede Anfrage kann über Postman oder cURL gefälscht werden
• Zu strenge Regeln — schrecken Benutzer ab: OWASP empfiehlt Mindestanforderungen bei der Registrierung
• Unicode ignorieren — die Längenprüfung in Bytes (nicht in Zeichen) bricht Russisch, Chinesisch und Emojis
• Nichtssagende Fehler — „Invalid format“ statt „Email must contain @ symbol after local part“
• Prüfung auf leeres Feld — if (value) unterscheidet eine leere Zeichenkette nicht von Null, false oder „0“

Die beste Praxis ist ein zentralisiertes Validierungssystem, das von Unit-Tests abgedeckt ist. Jede Regel sollte separat getestet werden: Grenzwerte, korrekte Daten, typische Angriffe (SQLi-Versuche, XSS-Payloads, sehr lange Zeichenketten). Regressionstests zur Validierung verhindern das versehentliche Abschwächen von Regeln beim Refactoring. Verwenden Sie property-basierte Tests (QuickCheck, fast-check), um zufällige Daten zu erzeugen und zu prüfen, dass die Validierung nicht mit einer Exception fehlschlägt.