Typische Regex-Fehler vermeiden: Quantoren, ReDoS und Über-Validierung

Reguläre Ausdrücke sind ein scharfes Werkzeug, und scharfe Werkzeuge verletzen schnell. Die meisten Probleme entstehen nicht aus exotischer Syntax, sondern aus wenigen wiederkehrenden Mustern: zu gierige Quantoren, gefährliche Verschachtelung, übertriebene Strenge und vergessene Maskierung. Wer diese Fallen kennt, schreibt Muster, die korrekt, schnell und sicher arbeiten.

Gierige gegen genügsame Quantoren

Die mit Abstand häufigste Fehlerquelle ist das Standardverhalten der Quantoren. Ein Quantor wie * oder + ist gierig: Er nimmt so viele Zeichen wie möglich und gibt nur durch Backtracking wieder ab, wenn der Rest des Musters sonst nicht passt. Das führt regelmäßig zu Treffern, die weit über das Gewollte hinausgehen.

Ein klassisches Beispiel ist das Extrahieren von Inhalten aus Tags. Das Muster <.+> angewandt auf <b>fett</b> trifft nicht etwa nur das erste Tag, sondern die gesamte Zeichenkette von der ersten spitzen Klammer bis zur letzten. Der Grund: Der gierige Quantor schluckt alles und gibt erst am Ende minimal zurück. Die genügsame Variante <.+?> mit angehängtem Fragezeichen nimmt dagegen so wenig wie möglich und trifft korrekt nur <b>.

Catastrophic Backtracking und ReDoS

Backtracking wird gefährlich, wenn ein Muster mehrere überlappende Wege hat, denselben Text zu zerlegen. Verschachtelte Quantoren wie in (a+)+$ sind das klassische Rezept. Solange ein Treffer existiert, fällt das nicht auf. Doch bei einer Eingabe, die fast passt und am Ende scheitert, probiert die Engine exponentiell viele Kombinationen durch, bevor sie aufgibt. Aus Millisekunden werden Sekunden, dann Minuten.

Diese Eigenschaft hat eine Sicherheitsdimension. Läuft ein verwundbares Muster gegen Eingaben, die ein Angreifer kontrolliert, spricht man von ReDoS, also Regular Expression Denial of Service. Eine einzige bösartig konstruierte Zeichenkette genügt, um einen Server-Thread für lange Zeit zu blockieren. Da viele Sprachen reguläre Ausdrücke mit einer rückverfolgenden Engine umsetzen, betrifft das Risiko zahlreiche Plattformen.

Der Ausweg liegt selten in cleveren Tricks, sondern in eindeutigen Mustern. Wer Alternativen so formuliert, dass sie sich gegenseitig ausschließen, und Quantoren nicht ineinander schachtelt, nimmt dem Backtracking die Grundlage. Atomare Gruppen oder besitzergreifende Quantoren helfen dort, wo die Engine sie unterstützt; die JavaScript-Engine bietet diese allerdings nicht durchgehend, weshalb hier die saubere Musterformulierung im Vordergrund steht.

Ein Muster, das mit einem Treffer schnell ist, kann mit einem Beinahe-Treffer den ganzen Prozess anhalten. Performance misst sich am schlimmsten Fall, nicht am Normalfall.

Über-Validierung: zu streng ist auch falsch

Ein verbreiteter Denkfehler ist die Annahme, eine Validierung sei umso besser, je strenger sie ist. Das Gegenteil ist oft der Fall. Das bekannteste Beispiel ist die E-Mail-Adresse. Die zugrunde liegende Syntax ist erstaunlich umfangreich, und die meisten selbstgebauten Muster lehnen gültige Adressen ab, etwa solche mit Pluszeichen im lokalen Teil, mit neuen Top-Level-Domains oder mit internationalen Zeichen.

Praktisch bedeutet das: Eine zu strenge Regex schließt echte Nutzer aus und erzeugt Support-Aufwand, ohne wirklich Sicherheit zu gewinnen. Eine lockere Plausibilitätsprüfung wie [^@\s]+@[^@\s]+\.[^@\s]+ fängt grobe Tippfehler ab und reicht für die meisten Formulare völlig aus. Den endgültigen Beweis, dass eine Adresse existiert und dem Absender gehört, liefert ohnehin nur eine Bestätigungs-Mail, nicht das Muster.

Maskieren und Anker vergessen

Zwei kleine Versäumnisse haben große Wirkung. Das erste ist die fehlende Maskierung. Viele Zeichen haben in regulären Ausdrücken eine Sonderbedeutung, darunter der Punkt, das Pluszeichen, die runde Klammer und der Stern. Wer einen Domainnamen wie example.de ohne Maskierung als example.de schreibt, erlaubt mit dem ungeschützten Punkt jedes beliebige Zeichen an dieser Stelle. Korrekt ist example\.de, da der maskierte Punkt wirklich nur einen Punkt meint.

Das zweite Versäumnis sind fehlende Anker. Ohne ^ am Anfang und $ am Ende prüft ein Muster nur, ob es irgendwo im String vorkommt, nicht, ob der gesamte String passt. Eine Postleitzahl-Prüfung \d{5} akzeptiert dadurch auch eine zwanzigstellige Zahl, weil fünf Ziffern irgendwo darin enthalten sind. Erst ^\d{5}$ stellt sicher, dass die Eingabe ausschließlich aus genau fünf Ziffern besteht.

Fehler, Symptom und Lösung im Überblick

Die folgende Tabelle ordnet die besprochenen Fehler ihrem typischen Symptom und der passenden Gegenmaßnahme zu.

Fehler	Symptom	Lösung
Gieriger Quantor	Treffer umfasst zu viel Text	Genügsamen Quantor +? oder negierte Zeichenklasse [^x] nutzen
Verschachtelte Quantoren	Auswertung hängt bei bestimmten Eingaben	Eindeutige, nicht überlappende Muster, Eingabelänge begrenzen
ReDoS-Verwundbarkeit	Server blockiert bei manipuliertem Input	Muster gegen Nutzer-Input prüfen und entschärfen
Über-Validierung	Gültige Eingaben werden abgelehnt	Lockere Plausibilitätsprüfung statt strenger Vollabdeckung
Vergessene Maskierung	Sonderzeichen trifft zu viel	Sonderzeichen mit Backslash maskieren, etwa \.
Fehlende Anker	Teiltreffer wird fälschlich akzeptiert	Mit ^ und $ den ganzen String binden

Performance und die Grenzen von Regex

Auch jenseits von ReDoS lohnt ein Blick auf die Geschwindigkeit. Anker grenzen den Suchraum früh ein und ersparen der Engine unnötige Versuche. Spezifische Zeichenklassen sind schneller als ein allgemeines ., weil sie weniger Backtracking erzeugen. Wer eine Regex in einer Schleife über große Datenmengen laufen lässt, kompiliert sie einmal außerhalb der Schleife, statt sie bei jedem Durchlauf neu zu erzeugen.

So schreibst du robustere Muster

Beginne jedes Muster mit der Frage, wie viel Text ein Quantor wirklich greifen soll, und entscheide bewusst zwischen gierig und genügsam. Prüfe jedes Muster, das auf fremde Eingaben trifft, auf verschachtelte Quantoren. Validiere großzügig statt übergenau und maskiere Sonderzeichen konsequent. Verankere, wo der ganze String passen muss.

Am schnellsten findest du solche Fehler, indem du das Muster live ausprobierst. Ein Regex-Tester zeigt in Echtzeit, was wirklich getroffen wird, und macht einen gierigen Quantor oder einen ungeschützten Punkt sofort sichtbar. Die Anleitungen zu Quantoren sowie zu Suchen und Ersetzen vertiefen die einzelnen Schritte. Wer die Bausteine noch einmal von Grund auf nachvollziehen möchte, findet sie in den Regex-Syntax-Grundlagen und im Überblick zu häufigen Regex-Mustern. Und wer komplexe Muster mit Gruppen und Bedingungen baut, profitiert vom Artikel zu Gruppen und Lookarounds, wo sich viele dieser Fehler von vornherein vermeiden lassen.