API Input Sanitization – Strings und Daten sicher bereinigen

Eine API bekommt Eingaben aus Formularen, Apps, Integrationen oder automatisierten Jobs. Und diese Eingaben sind selten so „sauber“, wie man es sich wünscht: Leerzeichen, andere Datumsformate, unerwartete Zeichen, sehr lange Texte oder Felder, die mal fehlen und mal leer sind. Genau hier hilft Input Sanitization: Daten werden in eine erwartbare Form gebracht, bevor sie weiterverarbeitet oder gespeichert werden.

Wichtig ist dabei eine klare Trennung: Sanitization „bereinigt“ (z. B. trimmt Leerzeichen), Input-Validierung entscheidet „gültig oder ungültig“ (z. B. E-Mail-Format passt oder nicht). Wer das vermischt, riskiert Sicherheitslücken oder stille Datenfehler. Für die Validierung im Backend lohnt sich ergänzend ein Blick auf Input-Validierung im Backend.

Input Sanitization vs. Validierung: was ist was?

Sanitization bedeutet „in Form bringen“

Sanitization ist eine Transformations-Schicht. Ziel: Daten sind konsistent und verursachen keine Überraschungen. Typische Beispiele:

• Whitespace entfernen:

  “ Max “ wird zu „Max“

• Mehrfach-Leerzeichen normalisieren:

  „Max Mustermann“ wird zu „Max Mustermann“

• Unicode vereinheitlichen (z. B. verschiedene Bindestriche oder Anführungszeichen)
• Leere Strings in

  null

  umwandeln, wenn das Feld semantisch „nicht gesetzt“ bedeutet

Validierung bedeutet „regelkonform oder Fehler“

Validierung prüft Regeln, die zur Fachlogik gehören: Pflichtfelder, Wertebereiche, Formate, erlaubte Zustände. Beispiel: Eine Postleitzahl muss aus genau 5 Ziffern bestehen (wenn das System nur dieses Format akzeptiert). Wenn die Prüfung fehlschlägt, sollte die API klar antworten (z. B. mit passenden HTTP-Statuscodes). Dazu passt: HTTP Statuscodes verstehen.

Warum das Trennen so wichtig ist

Wenn Sanitization versucht, Validierungsfehler „wegzuzaubern“, entstehen stille Fehler. Beispiel: Aus „12O45“ (Buchstabe O statt Null) wird durch „alle Nicht-Ziffern entfernen“ die „1245“ – plötzlich ist ein anderer Wert gespeichert. Besser: Sanitization macht nur sichere, nachvollziehbare Schritte; Validierung entscheidet anschließend.

Welche Daten in APIs typischerweise bereinigt werden

Strings: trimmen, normalisieren, begrenzen

Bei Strings sind kleine Korrekturen fast immer sinnvoll. Dazu zählen:

• Whitespace-Normalisierung: führende/abschließende Leerzeichen entfernen, mehrere Leerzeichen zu einem machen
• Unsichtbare Zeichen entfernen (z. B. Zero-Width-Spaces), wenn sie in der Oberfläche Probleme machen
• Maximale Länge begrenzen (nicht als Sicherheits-„Waffe“, sondern als Schutz vor Ausreißern)

Wichtig: Längenbegrenzungen gehören oft sowohl zur Sanitization (abschneiden) als auch zur Validierung (ablehnen). In APIs ist „ablehnen“ meistens besser, weil sonst Daten abgeschnitten werden, ohne dass es jemand merkt. Abschneiden passt eher bei rein kosmetischen Feldern, nicht bei Inhalten wie Adressen oder Beschreibungen.

Numbers und Booleans: typisieren statt raten

Viele Eingaben kommen als String, selbst wenn sie „eigentlich“ Zahlen sind. Sanitization kann hier helfen, aber ohne Ratespiele. Gute Regeln:

• Nur explizit konvertieren, wenn der Feldtyp eindeutig ist (z. B.

  age

  ist immer eine Zahl).

• Kein „alles rausfiltern, bis nur Ziffern übrig sind“ bei IDs oder Preisen. Das kann Werte verfälschen.
• Booleans klar behandeln:

  true/false

  akzeptieren, optional

  „true“/“false“

  – aber dann konsequent und dokumentiert.

Dates: ein Format akzeptieren, intern standardisieren

Datums- und Zeitangaben sind ein Klassiker für Inkonsistenzen. Praktisch ist: Die API akzeptiert ein klares Eingabeformat (Validierung) und speichert intern ein standardisiertes Format (Sanitization/Mapping). Wer mehrere Formate „freundlich“ akzeptiert, bekommt oft schwer reproduzierbare Edge Cases.

Für APIs, die mit Clients in verschiedenen Zeitzonen sprechen, lohnt sich außerdem eine feste Regel: Zeiten nur als UTC speichern und an den Rändern (Client/UI) in lokale Zeiten umrechnen.

Sanitization als Teil einer stabilen API-Pipeline

Wo Sanitization in der Request-Verarbeitung hingehört

Bewährt hat sich diese Reihenfolge:

• Request parsen (JSON/Form-Body)
• Input Sanitization (Form vereinheitlichen, Typen setzen, offensichtliche Ausreißer entschärfen)
• Input-Validierung (Regeln prüfen, Fehler sauber zurückgeben)
• Mapping in interne Modelle/Commands
• Persistenz/Business-Logik

So bleiben die Regeln nachvollziehbar: Sanitization macht Daten „vergleichbar“, Validierung macht sie „zulässig“.

Sanitization ist nicht XSS-Schutz (und auch nicht SQL-Schutz)

Ein häufiges Missverständnis: „Wenn die API HTML entfernt, ist alles sicher.“ Das stimmt nicht. XSS (Cross-Site Scripting) passiert meist dort, wo Daten im Browser wieder ausgegeben werden. Deshalb ist kontextabhängiges Escaping (z. B. in HTML, Attributen oder JavaScript) entscheidend. Die API kann HTML einschränken, aber das ersetzt keine sichere Ausgabe.

Ähnlich bei SQL: Eingaben „zu bereinigen“ ist kein Ersatz für Prepared Statements. Für PHP-Projekte ist das praxisnah erklärt in PHP Prepared Statements.

Logging: Sanitization darf Fehler nicht verstecken

Wenn Sanitization still „repariert“, wird Debugging unnötig schwer. Besser: Bei auffälligen Anpassungen entweder ablehnen oder zumindest strukturiert loggen (ohne sensible Daten). Eine gute Log-Strategie hilft dabei: Structured Logging.

Praktische Regeln für sichere Bereinigung

Regel 1: nur reversible oder harmlose Änderungen

„Harmlos“ bedeutet: Die Information bleibt erhalten. Beispiele: trimmen, Whitespace normalisieren, Unicode vereinheitlichen. Nicht harmlos sind: Zeichen entfernen, Inhalte kürzen, Format „erraten“.

Regel 2: pro Feld eine klare Verantwortlichkeit

Jedes Feld sollte eine kurze Definition haben: „Was ist das?“, „Welche Form wird akzeptiert?“, „Was wird intern gespeichert?“. Ohne diese Definitionen entsteht Wildwuchs: dieselbe Information sieht je nach Endpoint anders aus.

Regel 3: Kantenfälle bewusst entscheiden (null vs. leer)

In APIs ist der Unterschied wichtig:

• null

  bedeutet oft: „nicht gesetzt“ oder „unbekannt“

• „“

  (leer) bedeutet: „absichtlich leer“ oder „User hat alles gelöscht“

Sanitization kann hier vereinheitlichen, aber nur, wenn die Semantik klar ist. Eine häufige Entscheidung: Leere Strings bei optionalen Textfeldern in

null

umwandeln, damit Filter/Queries einfacher werden. Bei Feldern, die „leer“ als echten Zustand brauchen (z. B. Freitextnotiz), sollte

„“

erhalten bleiben.

Regel 4: Grenzwerte nicht heimlich „zurechtbiegen“

Wenn ein Feld maximal 100 Zeichen erlaubt, ist „abschneiden“ selten fair. Besser ist eine klare Fehlermeldung. Das reduziert Support-Fälle und verhindert Datenverlust.

So entsteht eine einfache Sanitization-Schicht (ohne Framework-Zwang)

Ein kleines Muster: sanitize → validate → map

Unabhängig von Sprache oder Framework hilft ein simples Muster:

• sanitize(input) -> sanitized

• validate(sanitized) -> errors oder ok

• map(sanitized) -> internes Objekt/DTO

So ist der Code leichter testbar: Sanitization-Tests prüfen nur Transformation, Validierungstests prüfen Regeln, Mapping-Tests prüfen Felder.

Mini-Fallbeispiel: Profil-Update Endpoint

Ein Endpoint

PATCH /profile

bekommt

displayName

,

website

,

bio

.

• displayName

  : trimmen, Mehrfach-Leerzeichen normalisieren

• website

  : trimmen, leere Strings zu

  null

• bio

  : trimmen, aber keine aggressiven Änderungen (User-Text ist Inhalt)

Danach Validierung:

displayName

Pflicht, minimale/maximale Länge;

website

muss URL-Format haben, wenn gesetzt;

bio

optional, aber maximale Länge.

Kurze Box für den Alltag

• Sanitization nur für sichere, erklärbare Anpassungen nutzen (trimmen, normalisieren, typisieren).
• Validierung immer danach ausführen und Fehler klar zurückgeben.
• Canonicalisierung (einheitliche Darstellung) bevorzugen: ein Format rein, ein Format raus.
• Keine Sicherheitsversprechen durch „HTML entfernen“; XSS/SQL-Schutz gehört an andere Stellen.
• Sanitization-Funktionen klein halten und pro Feld testen.

Vergleich: Bereinigen, Validieren, Escapen

Häufige Fragen aus der Praxis

Sollte eine API HTML in Textfeldern erlauben?

Für viele Business-Anwendungen ist „nur Text“ die einfachste und sicherste Wahl. Wenn HTML nötig ist (z. B. für Rich-Text), braucht es klare Regeln: welche Tags/Attribute erlaubt sind, wie gespeichert wird und wie die Ausgabe abgesichert wird. Ohne diese Regeln steigt das Risiko für XSS deutlich.

Ist „sanitize everything“ eine gute Strategie?

Nein. Sanitization sollte gezielt sein. Wer alles pauschal verändert, übersieht leicht, dass manche Felder Inhalt transportieren (z. B. Nachrichten, Kommentare, Code-Snippets) und nicht „normalisiert“ werden sollten.

Wo liegt Sanitization am besten: im Controller oder im Model?

Praktisch ist eine eigene Schicht nah an der Request-Grenze (z. B. Request-Mapper/DTO). So bleibt die Business-Logik frei von „Eingabe-Aufräumen“ und kann davon ausgehen, dass Daten bereits eine konsistente Form haben.