Open Redirect: Schwachstelle erkennen & verhindern (2026)

Sicherheitslücken in Webanwendungen gibt es viele, aber einige fallen erst auf, wenn sie aktiv ausgenutzt werden. Open Redirects sind genau so ein Fall. Die Schwachstelle wirkt harmlos: Der Nutzer erhält einen 3xx-Statuscode und wird zu einer anderen URL geschickt. Genau diese scheinbare Belanglosigkeit macht sie gefährlich, denn der Angreifer borgt sich das Vertrauen und das gültige TLS-Zertifikat Ihrer Domain, um Menschen auf seine eigene Seite zu lenken.

Dass das Thema aktuell ist, zeigen Beobachtungsdaten aus dem Feld: Das SANS Internet Storm Center dokumentierte im Februar 2026 einen deutlichen Anstieg des Scan-Volumens nach offenen Redirect-Endpunkten, mit Mustern wie /continue?url=, /redirect?url=, /away?url=, /goto?url= und /jump?url=. Open Redirects sind also keineswegs eine vergessene Altlast, sondern ein aktiv gesuchtes Einfallstor.

Dieser Artikel erklärt Open Redirects von Grund auf und geht dann bewusst tiefer als die meisten Übersichten: Sie bekommen eine vollständige, benannte Bypass-Serie, die zeigt, warum naive Prüfungen scheitern, mit den zentralen Bypass-Klassen verankert an realen, gegen die NVD geprüften CVEs. Danach folgt ein bypass-resistenter Validator, den Sie in Node.js, Python und Java direkt übernehmen können und der jede dieser Umgehungen tatsächlich abwehrt.

Was ist ein Open Redirect?

Ein Open Redirect (technisch CWE-601, "URL Redirection to Untrusted Site") entsteht, wenn eine Anwendung eine vom Nutzer kontrollierte Eingabe als Ziel einer Weiterleitung verwendet, ohne zu prüfen, ob dieses Ziel vertrauenswürdig ist. Meist steckt die Ziel-URL in einem Query-Parameter:

<a href="https://example.com/redirect?url=https://evilpage.com">Hier klicken</a>

Validiert die Anwendung den Parameter nicht, landet der Nutzer auf der bösartigen Seite. Der minimale verwundbare Code sieht in praktisch jeder Sprache gleich aus. So dokumentiert es auch das OWASP-Cheat-Sheet als plattformübergreifendes Muster, hier in PHP:

$redirect_url = $_GET['url'];
header("Location: " . $redirect_url);

Wichtig für die Einordnung: Nicht jede externe Weiterleitung ist automatisch eine Schwachstelle. Suchmaschinen etwa leiten absichtlich auf beliebige Ziele weiter. Zum Problem wird es dort, wo die Anwendung eine Weiterleitung anbietet, die nur intern gedacht war, und ein Angreifer das Ziel frei bestimmen kann.

Editionsscharfe Einordnung in die OWASP Top 10

Rund um die Historie der OWASP Top 10 kursieren viele halbrichtige Angaben. Die belegbare Kette sieht so aus:

• 2010: Open Redirect wird erstmals als eigene Kategorie A10:2010 "Unvalidated Redirects and Forwards" aufgenommen, auf dem letzten Listenplatz.
• 2013: Die Kategorie bleibt eigenständig als A10:2013. Die offizielle CWE-Taxonomie (CWE-938) führt für diese Kategorie genau ein Mitglied: CWE-601. Die verbreitete Behauptung, Open Redirect sei bereits 2013 in "Sensitive Data Exposure" aufgegangen, ist damit falsch.
• 2017: Die Kategorie wird aus den Top 10 entfernt, weil ihre Prävalenz zu niedrig war.
• 2021: CWE-601 kehrt zurück, jetzt nicht mehr als eigene Kategorie, sondern als eine von 34 CWEs unter A01:2021 Broken Access Control, der Kategorie, die von Platz 5 auf Platz 1 aufstieg.
• 2025: CWE-601 bleibt unter A01:2025 Broken Access Control. Bemerkenswert: In dieser Ausgabe liegt CWE-918 (Server-Side Request Forgery, SSRF) in derselben Kategorie. Open Redirect und SSRF sind damit nicht nur thematisch verwandt, sondern offiziell taxonomisch zusammengeführt.

Zur Klarstellung, weil eine bekannte Lernplattform (Snyk Learn) es anders angibt: CWE-601 ist unter Broken Access Control (A01) gemappt, nicht unter A03 Injection. Maßgeblich ist die "CWEs Mapped"-Liste der offiziellen OWASP-Kategorieseiten.

Praktische Angriffsszenarien

1. Phishing mit legitimen Domains

Der Klassiker. Ein Angreifer nutzt eine seriös wirkende URL, um das Opfer auf eine gefälschte Seite zu lenken:

https://trusted-bank.com/login?redirect=https://hacker-site.com/fake-login

Der Nutzer sieht die Domain seiner Bank, ein gültiges Zertifikat und schöpft keinen Verdacht, landet aber auf einer nachgebauten Login-Seite. Große, vertrauenswürdige Plattformen sind besonders attraktiv als Sprungbrett: Dokumentiert ist etwa der Missbrauch eines Baidu-Redirects für Phishing. 2024 trat das Muster verstärkt in Kombination mit Quishing auf, also QR-Code-Phishing, bei dem ein QR-Code auf einen Open-Redirect-Endpunkt einer legitimen Domain zeigt und von dort weiterleitet.

2. Open Redirect als Teil einer XSS-Kette

Kann ein Angreifer den Anfang der Redirect-Zeichenkette kontrollieren, lässt sich ein Open Redirect in eine JavaScript-Injektion eskalieren. Statt einer http-URL wird ein Pseudo-Protokoll eingeschleust:

javascript:alert(document.domain)

Besonders relevant ist das bei DOM-basierten Redirects, bei denen clientseitiges JavaScript einen Wert aus der URL in eine Navigations-Senke schreibt. PortSwigger listet als verwundbare Senken unter anderem location, location.href, location.assign() und location.replace(). Ein typisches verwundbares Muster:

let url = /https?:\/\/.+/.exec(location.hash);
if (url) { location = url[0]; }

Wie sich solche Skript-Ausführung im Detail verhindern lässt, behandeln wir ausführlich in unserem Beitrag zu den XSS-Grundlagen.

3. Malware-Downloads

Open Redirects können Nutzer unbemerkt auf Seiten führen, die automatisiert Schadsoftware ausliefern oder Exploit-Kits hosten. Der Nutzer klickt auf einen Link, der auf Ihre Domain zeigt, und landet auf einer Drive-by-Download-Seite.

4. OAuth und der Parameter redirect_uri

Im OAuth-2.0-Flow ist redirect_uri das Ziel, an das der Autorisierungsserver den Nutzer samt Autorisierungscode zurückschickt. Wird dieser Parameter nicht streng geprüft, wird der Autorisierungsserver selbst zum offenen Weiterleiter, und ein Angreifer kann den Autorisierungscode oder das Token abgreifen.

Die von der OAuth-Arbeitsgruppe empfohlene Regel ist eindeutig: exaktes String-Matching gegen die vorab registrierten Redirect-URIs. Kein Präfix-, kein Substring- und kein Wildcard-Vergleich, und selbst ein nachgestellter Schrägstrich (/callback gegen /callback/) zählt als Nichtübereinstimmung, die abgelehnt werden muss. Dass das kein theoretisches Problem ist, zeigt CVE-2026-5467: In der IAM-Lösung Casdoor (Version 2.356.0) erlaubte der OAuth Authorization Request Handler eine unzureichend geprüfte redirect_uri-Manipulation (CWE-601, CVSS 6.1 MEDIUM laut NIST). Das SANS ISC formuliert die Gefahr treffend: Ein Open Redirect innerhalb des erlaubten URL-Bereichs kann genutzt werden, um das Token zu unterwandern.

5. Kombination mit CSRF und die Brücke zu SSRF

In Verbindung mit Cross-Site Request Forgery kann ein Open Redirect helfen, ein Opfer unauffällig umzulenken, während im Hintergrund eine ungewollte Aktion ausgelöst wird.

Noch enger ist die Verwandtschaft zu Server-Side Request Forgery: Ein Server, der einer vom Nutzer gelieferten URL folgt und dabei einer Weiterleitung vertraut, lässt sich über einen Open Redirect an einer Host-Allowlist vorbeiführen. Dieselbe Parser-Diskrepanz, die einen Redirect ermöglicht, öffnet serverseitig SSRF. Genau deshalb liegen CWE-601 und CWE-918 in der Ausgabe 2025 in derselben OWASP-Kategorie. Invicti nennt zusätzlich den CSP-Bypass: Steht eine an sich vertrauenswürdige Domain in einer Content-Security-Policy und besitzt sie selbst einen Open Redirect, lässt sich die Richtlinie aushebeln.

Warum naive Prüfungen scheitern: die Bypass-Serie

Der teuerste Fehler bei Open Redirects ist der Glaube, eine kurze String-Prüfung reiche aus. Sie reicht nicht. Die folgende Serie zeigt die klassischen Umgehungen, jeweils mit Payload und Erklärung, warum sie greift. Nehmen wir an, die vertrauenswürdige Domain heißt trusted.com.

Protokoll-relative URLs. Ein Filter, der nur das Schlüsselwort http sperrt, übersieht die protokoll-relative Schreibweise. Der Browser ergänzt das aktuelle Schema selbst:

//evil.com
////evil.com

Backslash-Tricks. Chrome und andere Browser behandeln \ in Pfaden faktisch wie /. Ein Filter, der nur // blockt, wird so umgangen, und https:/\evil.com wird vom Browser als https://evil.com interpretiert:

/\evil.com
\/\/evil.com
https:/\evil.com

Das @-Zeichen (Userinfo). Nach der klassischen URL-Syntax (RFC 1738, heute abgelöst durch RFC 3986) hat die URL-Autorität die Form //<user>:<password>@<host>. Alles vor dem @ ist die Userinfo-Komponente, nicht der Host:

https://[email protected]

Diese URL sieht aus wie ein Link zu trusted.com, navigiert aber zu evil.com, weil trusted.com nur als Benutzername interpretiert wird. Genau diese Klasse tauchte 2024 in einem Bugbounty-Fall bei Tumblr auf, in Kombination mit dem Backslash-Trick.

Whitelist-Substring-Fehler. Wer nur prüft, ob der Ziel-String die vertrauenswürdige Domain "enthält", ist verloren:

trusted.com.evil.com
evil.com/trusted.com

Im ersten Fall ist der echte Host evil.com (mit trusted.com als Subdomain-Präfix), im zweiten ist trusted.com nur ein Pfadsegment. Ein realer, gegen die NVD geprüfter Beleg ist CVE-2026-25477 in AFFiNE (Versionen bis 0.25.7, behoben in 0.26.0, CWE-601, CVSS 6.1 MEDIUM laut NIST). Der verwundbare Endpunkt /redirect-proxy prüfte die Ziel-Domain mit diesem regulären Ausdruck:

new RegExp(`.?${domain}$`).test(target.hostname)

Der Fehler steckt im Detail: Der Punkt in .? ist ein unescapetes Regex-Metazeichen und passt auf jedes beliebige Zeichen, und das Muster ist am Wortanfang nicht verankert. Stand t.me in der Allowlist, akzeptierte der Ausdruck deshalb auch affineredirect.me, weil der String am Ende auf eine passende Zeichenfolge trifft. Angreifer konnten so über einen offiziell aussehenden AFFiNE-Link auf eine täuschend ähnliche Domain umleiten.

Fehlendes Schema und die startsWith("/")-Falle. Eine beliebte, aber unsichere Kurzprüfung lautet: "Wenn die URL mit / beginnt, ist sie lokal." Das ist falsch, denn //evil.com beginnt ebenfalls mit /, ist aber protokoll-relativ, und /\evil.com beginnt mit /, wird vom Browser aber als //evil.com gelesen. Eine sichere relative Prüfung muss also verlangen: genau ein führender Schrägstrich, niemals // und niemals /\.

Unicode- und IDN-Tricks. Über Unicode-Normalisierung lassen sich Host-Grenzen verschieben. Der Vollbreiten-Punkt 。 (%E3%80%82) umgeht eine Blacklist auf das Zeichen ., und Kompatibilitätsligaturen können einen Host beim Normalisieren aufspalten:

//google%E3%80%82com
https://evil.c℀.example.com

Doppelte und uneinheitliche Encodings. Der gefährlichste Mechanismus ist die Parser-Diskrepanz: Anwendungscode, Framework und Browser interpretieren dieselbe Zeichenkette unterschiedlich. Genau hier saß CVE-2024-29041 in Express.js (behoben in 4.19.2 und 5.0.0-beta.3, klassifiziert als CWE-601 und CWE-1286, CVSS 6.1 MEDIUM). Express wendete intern encodeurl auf die URL an, bevor es sie in den Location-Header schrieb. Bei malformten URLs wich das, was der Browser am Ende ansteuerte, von dem ab, was eine korrekt implementierte Allowlist zuvor geprüft hatte. Dieselbe Klasse traf Spring Framework in CVE-2024-22243 (betroffen 5.3.x vor 5.3.32, 6.0.x vor 6.0.17, 6.1.x vor 6.1.4, CVSS 8.1 HIGH laut CNA, VMware). Hier parste UriComponentsBuilder eine externe URL anders, als sie später tatsächlich verwendet wurde, und die NVD klassifiziert denselben Bug ausdrücklich sowohl als Open Redirect als auch als SSRF.

Die Lehre aus diesen drei CVEs: Es genügt nicht, "irgendeine" Parsing-Bibliothek zu benutzen. Prüf-Ergebnis und tatsächlich verwendete URL müssen aus derselben normalisierten Repräsentation stammen, sonst sitzt der Bypass genau in der Lücke dazwischen.

Der bypass-resistente Validator: Parsen statt Vergleichen

Aus der Bypass-Serie folgen drei Prinzipien, die jeder sichere Validator umsetzen muss:

1. Vollständig parsen, dann den Host exakt vergleichen. Nie den rohen String durchsuchen, immer den geparsten Host gegen eine Allowlist prüfen, mit exakter Gleichheit, nicht per Substring oder Suffix.
2. Relative Ziele streng definieren. Erlaubt ist ausschließlich ein Pfad mit genau einem führenden Schrägstrich. //, /\ und schemelose Hostnamen werden abgelehnt.
3. Prüfung und Verwendung dürfen nicht auseinanderlaufen. Backslash-Varianten werden zusätzlich in ihrer normalisierten Form geprüft (der Trick, den auch Django verwendet), und nur das Schema http oder https ist zulässig.

Bevor Sie überhaupt Code schreiben, lohnt der Blick auf die kanonische OWASP-Hierarchie: Am sichersten ist es, Redirects zu vermeiden. Ist eine Weiterleitung nötig, sollte der Nutzer nur einen Identifikator übergeben, den der Server serverseitig auf eine fest hinterlegte URL abbildet (Mapping). Erst wenn wirklich freie Ziele nötig sind, kommt die Host-Allowlist ins Spiel. Als letzte Stufe bleibt eine Bestätigungsseite, die das Ziel anzeigt.

Alle folgenden Validatoren wurden gegen die komplette Bypass-Serie aus dem vorigen Abschnitt geprüft. Node.js und Python wurden ausgeführt und wehren jeden Payload ab, der Java-Validator ist per Logik-Review (nicht zur Laufzeit) gegen dieselbe Serie abgesichert und folgt derselben verifizierten Logik.

Node.js / Express (WHATWG URL)

Die offizielle Fix-Empfehlung aus der Express-Advisory lautet, die URL vor jeder Verwendung mit new URL vorzuparsen. Genau das tut dieser Helfer:

const ALLOWED_HOSTS = new Set(['trusted.com', 'www.trusted.com']);

function safeRedirectTarget(input) {
  if (typeof input !== 'string' || input === '') return null;

  // 1) Relatives Ziel: genau ein führender Slash, niemals "//" oder "/\"
  if (input.startsWith('/') && !input.startsWith('//') && !input.startsWith('/\\')) {
    return input;
  }

  // 2) Absolute URL: der WHATWG-Parser bestimmt den echten Host
  let url;
  try {
    url = new URL(input);
  } catch {
    return null; // weder parsebare absolute URL noch sauberer relativer Pfad
  }
  if (url.protocol !== 'http:' && url.protocol !== 'https:') return null;
  if (!ALLOWED_HOSTS.has(url.hostname)) return null;
  return url.href;
}

// Verwendung in Express:
app.get('/redirect', (req, res) => {
  const target = safeRedirectTarget(req.query.url);
  return res.redirect(target || '/');
});

Warum das hält: new URL('https://[email protected]').hostname ist evil.com, nicht trusted.com, und fällt aus der Allowlist. //evil.com und https:/\evil.com werden durch den Parser auf evil.com aufgelöst und abgelehnt. trusted.com.evil.com ist kein gültiger absoluter URL-String und beginnt nicht mit /, also durchfällt es beide Zweige.

Python: Django als Referenz und ein Flask-Helfer

Django löst das Problem in django.utils.http.url_has_allowed_host_and_scheme produktionsreif. Der entscheidende Kniff: Die Funktion prüft die URL zweimal, einmal im Original und einmal mit \ durch / ersetzt, weil Chrome Backslashes wie Schrägstriche behandelt.

from django.utils.http import url_has_allowed_host_and_scheme

if url_has_allowed_host_and_scheme(target, allowed_hosts={"trusted.com"}, require_https=True):
    return redirect(target)
return redirect("/")

Für Flask oder ein anderes Framework lässt sich dasselbe Prinzip kompakt nachbauen. Dieser Helfer wurde ausgeführt und wehrt die gesamte Bypass-Serie ab:

from urllib.parse import urlsplit
import unicodedata

ALLOWED_HOSTS = {"trusted.com", "www.trusted.com"}


def is_safe_redirect(target, allowed_hosts=ALLOWED_HOSTS):
    if not target:
        return False
    target = target.strip()
    # Roh- UND backslash-normalisierte Form pruefen (Djangos Trick): Chrome
    # behandelt "\" wie "/", ein Angreifer koennte so einen Host einschmuggeln.
    return _check(target, allowed_hosts) and _check(target.replace("\\", "/"), allowed_hosts)


def _check(url, allowed_hosts):
    # Drei oder mehr fuehrende Slashes gelten fuer Browser als absolut,
    # fuer urlsplit nicht -> ablehnen.
    if url.startswith("///"):
        return False
    # Fuehrende Steuerzeichen ignorieren manche Browser -> ablehnen.
    if unicodedata.category(url[0])[0] == "C":
        return False
    try:
        parts = urlsplit(url)
    except ValueError:
        return False
    # Schema vorhanden, aber kein Host (http:///evil.com) -> ablehnen.
    if parts.scheme and not parts.netloc:
        return False
    scheme = parts.scheme or ("http" if parts.netloc else "")
    if scheme and scheme not in ("http", "https"):
        return False
    if not parts.netloc:
        # Kein Host: nur einen echten absoluten Pfad ("/dashboard") zulassen,
        # niemals ein blankes "trusted.com.evil.com".
        return url.startswith("/")
    # Host vorhanden: er muss EXAKT auf der Allowlist stehen. hostname
    # entfernt ein "user:info@"-Praefix, "[email protected]" wird als
    # evil.com geprueft.
    return parts.hostname in allowed_hosts

Java / Spring (java.net.URI mit exaktem Host-Vergleich)

Die Lehre aus CVE-2024-22243 ist wichtig: Die bloße Existenz einer Parsing-Klasse wie UriComponentsBuilder schützt nicht, wenn geprüfte und verwendete URL auseinanderlaufen können. Verlassen Sie sich auf java.net.URI, parsen Sie vollständig und vergleichen Sie den Host exakt nach dem Parsen:

import java.net.URI;
import java.util.Set;

public final class RedirectValidator {

    private static final Set<String> ALLOWED_HOSTS =
        Set.of("trusted.com", "www.trusted.com");

    /** Liefert ein sicheres Ziel oder "/" fuer alles Nicht-Vertrauenswuerdige. */
    public static String safeTarget(String input) {
        if (input == null || input.isEmpty()) {
            return "/";
        }
        // Browser behandeln "\" wie "/": Roh- UND normalisierte Form pruefen.
        if (isSafe(input) && isSafe(input.replace("\\", "/"))) {
            return input;
        }
        return "/";
    }

    private static boolean isSafe(String value) {
        // Protokoll-relative ("//evil.com") und Mehrfach-Slash-Formen: unsicher.
        if (value.startsWith("//")) {
            return false;
        }
        // Ein einzelner fuehrender Slash ist ein echter relativer Pfad -> sicher.
        if (value.startsWith("/")) {
            return true;
        }
        try {
            URI uri = new URI(value);
            String scheme = uri.getScheme();
            if (scheme == null) {
                // Kein Schema, kein fuehrender Slash -> ablehnen (trusted.com.evil.com).
                return false;
            }
            if (!scheme.equals("http") && !scheme.equals("https")) {
                return false;
            }
            String host = uri.getHost();
            // getHost() ist null bei malformter Autoritaet -> bei null ablehnen.
            return host != null && ALLOWED_HOSTS.contains(host);
        } catch (Exception e) {
            return false;
        }
    }
}

Ein wichtiger Hinweis zu java.net.URI: Bei bestimmten ungültigen Autoritäten gibt getHost() null zurück. Der sichere Standard ist deshalb, bei null grundsätzlich abzulehnen, statt auf den rohen Autoritäts-String auszuweichen.

Und die generelle Wahrheit, die schon der Django-Quellcode in einem Kommentar festhält: Ein true aus einem Host-Check bedeutet nicht automatisch "sicher". Die Host-Validierung ist notwendig, aber nur ein Baustein eines defensiven Gesamtdesigns.

Welche Tools helfen, Open Redirects zu finden?

• Burp Suite: Fängt HTTP-Anfragen ab und manipuliert sie, ideal, um die Bypass-Serie manuell gegen einen Endpunkt durchzuspielen.
• OWASP ZAP: Quelloffener Scanner, der automatisiert auf unsichere Weiterleitungen testet und sie dokumentiert.
• Google Dorks: Über gezielte Suchanfragen wie site:example.com inurl:redirect= lassen sich verdächtige Parameter aufspüren.
• Nikto: Web-Scanner, der bekannte Schwachstellenmuster einschließlich unsicherer Redirects erkennt.
• Manuelles Testen mit den DevTools: Redirect-Parameter im Browser verändern und die Reaktion der Anwendung beobachten.
• Unit-Tests gegen die Bypass-Serie: Der wirksamste Entwickler-seitige Schutz. Machen Sie die Payloads aus diesem Artikel zu festen Testfällen Ihres Validators, so wie die hier gezeigten Validatoren gegen genau diese Liste geprüft wurden.

Häufige Fragen

Was ist ein Open Redirect?

Ein Open Redirect ist eine Schwachstelle (CWE-601), bei der eine Anwendung eine vom Nutzer kontrollierte Eingabe als Ziel einer Weiterleitung verwendet, ohne zu prüfen, ob dieses Ziel vertrauenswürdig ist. Meist steckt die Ziel-URL in einem Query-Parameter wie ?url=. Ein Angreifer kann das Ziel dann frei bestimmen und Nutzer von einer seriös wirkenden Domain auf eine beliebige fremde Seite lenken.

Ist ein Open Redirect gefährlich?

Ja. Als Einzelbug wird ein Open Redirect meist als mittelschwer eingestuft (häufig CVSS 6.1), seine eigentliche Gefahr liegt aber in der Verstärkerwirkung: Er borgt sich das Vertrauen und das gültige TLS-Zertifikat Ihrer Domain und dient als Sprungbrett für Phishing, XSS, CSRF und SSRF. Aktuelle Scan-Daten des SANS Internet Storm Center zeigen, dass offene Redirect-Endpunkte aktiv gesucht werden.

Wie kann man Open Redirects verhindern?

Der Kernfehler ist fast immer, Strings zu vergleichen statt URLs zu parsen. Parsen Sie die Ziel-URL vollständig, vergleichen Sie den geparsten Host exakt gegen eine Allowlist (nicht per Substring oder Suffix), lassen Sie als relatives Ziel nur einen Pfad mit genau einem führenden Schrägstrich zu und prüfen Sie Backslash-Varianten zusätzlich in normalisierter Form. Am sichersten ist es, freie Redirects ganz zu vermeiden und stattdessen einen Identifikator serverseitig auf eine fest hinterlegte URL abzubilden.

Was hat Open Redirect mit OAuth und dem Parameter redirect_uri zu tun?

Im OAuth-2.0-Flow ist redirect_uri das Ziel, an das der Autorisierungsserver den Nutzer samt Autorisierungscode zurückschickt. Wird dieser Parameter nicht streng geprüft, wird der Autorisierungsserver selbst zum offenen Weiterleiter, und ein Angreifer kann Code oder Token abgreifen. Die OAuth-Arbeitsgruppe verlangt deshalb exaktes String-Matching gegen die vorab registrierten URIs, ohne Präfix-, Substring- oder Wildcard-Vergleich.

Zu welcher OWASP-Top-10-Kategorie gehört ein Open Redirect?

Open Redirect ist als CWE-601 seit der Ausgabe 2021 unter A01 Broken Access Control eingeordnet und bleibt dort auch in A01:2025. In der Ausgabe 2025 liegt zudem CWE-918 (SSRF) in derselben Kategorie, Open Redirect und SSRF sind damit taxonomisch zusammengeführt. Früher (2010 und 2013) war Open Redirect eine eigene Kategorie A10 "Unvalidated Redirects and Forwards".

Fazit

Open Redirects sind eine unterschätzte, aber real ausgenutzte Schwachstelle, wie die aktuellen Scan-Daten und eine ganze Reihe frischer CVEs in Mainstream-Frameworks belegen. Der entscheidende Denkfehler ist fast immer derselbe: Man vergleicht Strings, statt URLs zu parsen. Wer den Host erst vollständig parst, ihn dann exakt gegen eine Allowlist prüft, relative Ziele auf genau einen führenden Schrägstrich einschränkt und Backslash-Varianten zusätzlich normalisiert, schließt die gesamte Bypass-Serie. Für OAuth gilt zusätzlich die Exact-Match-Pflicht bei redirect_uri. Und weil Open Redirect als Verstärker für Phishing, XSS, CSRF und SSRF wirkt, lohnt sich diese Sorgfalt doppelt. Machen Sie die Payloads aus diesem Artikel zu Testfällen, bevor es ein Angreifer für Sie tut.