Redirection Ouverte (Open Redirect)

Qu'est-ce qu'une Redirection Ouverte ?#

Une redirection ouverte est une classe de vulnérabilité sous CWE-601 (URL Redirection to Untrusted Site) où une application accepte une URL dans un paramètre de requête et redirige le navigateur vers cette destination sans valider que la cible est un hôte autorisé. Le mécanisme de redirection existe pour des raisons légitimes — renvoyer l'utilisateur vers la page qu'il essayait d'atteindre après connexion, ou le retourner vers l'application appelante après un flux OAuth. La vulnérabilité apparaît quand l'URL de destination est prise telle quelle depuis une entrée contrôlée par l'attaquant.

La forme serveur émet un HTTP 302 (ou 301, 303, 307) avec un header Location contenant l'URL de l'attaquant. Le navigateur le suit automatiquement. La forme côté client utilise JavaScript : window.location = valeurParam. Les deux relèvent d'OWASP A01:2025 (Broken Access Control) car elles permettent de rediriger les utilisateurs hors de la limite de contrôle de l'application.

Une redirection ouverte obtient CVSS 6.1 en isolation — Moyen, souvent noté Faible dans les programmes avec des seuils élevés. Le vrai multiplicateur de gravité vient du chaînage. Une redirection ouverte sur un endpoint d'autorisation OAuth laisse fuiter le code d'autorisation : CVE-2019-3778 de Spring Security OAuth est le cas d'école, le NVD notant la fuite du code 6.5 alors que la prise de contrôle de compte qu'elle permet est ce que les programmes paient (NVD, CVE-2019-3778). Une redirection ouverte sur un domaine dans une allowlist SSRF est ce qu'exploite CVE-2025-4123 de Grafana — la redirection chaînée avec une traversée de chemin côté client jusqu'à un XSS de plugin frontend et, avec le plugin Image Renderer installé, un SSRF en lecture complète, noté 7.6 (Élevé) par Grafana (avis de sécurité Grafana, 21 mai 2025). CWE-601 est l'une des classes les plus régulièrement rapportées en bug bounty : l'index CWE discovery de HackerOne recense 17 199 signalements uniques de redirection ouverte depuis l'origine — 7e rang des 25 classes de faiblesse que l'index publie — avec 280 nouveaux signalements sur les douze semaines précédant le 15 octobre 2026, soit un recul de 1 % sur la période (index CWE discovery de HackerOne, relevé du 15 octobre 2026). Dans la base CVE, cette classe est bien plus rare : l'étude NDSS 2025 "Do (Not) Follow the White Rabbit: Challenging the Myth of Harmless Open Redirection" (Khodayari, Glauber et Pellegrino) la mesure à 1 % des 237 470 entrées CVE, contre 37 % pour le XSS, et a escaladé plus de 11,5 % des redirections ouvertes trouvées, sur 38 % des sites touchés, en XSS, CSRF ou fuite d'information (NDSS Symposium 2025, article 2025-523).

Mécanisme#

Le motif de base est une redirection côté serveur via paramètre :

GET /login?next=https://attacker.com HTTP/1.1
Host: banque-de-confiance.com
 
HTTP/1.1 302 Found
Location: https://attacker.com

Le navigateur suit le header Location vers attacker.com. L'utilisateur voit banque-de-confiance.com dans sa barre d'adresse pendant la requête initiale — la confiance est établie avant que la redirection se produise.

sequenceDiagram
  participant U as Utilisateur
  participant B as Navigateur
  participant S as banque-de-confiance.com
  participant A as attacker.com

  U->>B: Clique sur lien de phishing vers banque-de-confiance.com/login?next=https://attacker.com
  B->>S: GET /login?next=https://attacker.com
  Note over B: L'utilisateur voit banque-de-confiance.com dans la barre d'adresse
  S-->>B: 302 Location: https://attacker.com
  B->>A: GET / (le navigateur suit la redirection)
  A-->>B: Page de phishing
  Note over U: L'utilisateur croit être sur banque-de-confiance.com

La chaîne de redirection se déroule en trois étapes :

1. L'utilisateur reçoit une URL forgée — le domaine initial est de confiance, les filtres email et previews de liens affichent un domaine légitime.
2. Le serveur émet un 30x — l'application lit req.query.next et le passe directement à res.redirect() sans validation d'hôte.
3. Le navigateur suit Location — l'utilisateur atterrit sur le serveur de l'attaquant.

Variantes d'Attaque#

Bypass par Différentiel de Parseur URL#

from urllib.parse import urlparse
 
# Python voit ceci comme un chemin sans netloc — "sûr"
urlparse("\\evil.com").netloc  # Retourne '' — Python pense que netloc est vide
urlparse("%09https://evil.com").netloc  # Retourne '' — tab supprimé, pas de schéma
 
# Mais WHATWG (Chrome/Firefox) normalise :
# \\evil.com → //evil.com → https://evil.com (navigateur suit)
# %09https://evil.com → https://evil.com (navigateur décode le tab, analyse l'URL absolue)

Payloads de bypass actifs (liste Diverto 2024) :

//attacker.com               # Protocol-relative — les deux slashes requis
https:////attacker.com       # Slashes multiples — WHATWG élimine les extras
https:\attacker.com          # Antislash — WHATWG normalise en /
https://trusted.com@evil.com # Userinfo — trusted.com est le nom d'utilisateur
https://trusted.com.evil.com # Abus de suffixe — valide l'hostname complet, pas endsWith
%EF%BC%8E                    # Point pleine largeur Unicode — normalisation → .

Exemples Réels#

CVE-2025-4123 — Grafana (CVSS 6.1 (NVD)) L'avis de Grafana (21 mai 2025) décrit un XSS construit à partir de deux failles : une traversée de chemin côté client combinée à une redirection ouverte. La redirection envoie la victime vers un site qui héberge un plugin frontend, lequel exécute du JavaScript arbitraire — aucune permission d'éditeur requise, et avec l'accès anonyme activé le XSS se déclenche sans session. Grafana le note 7.6 (Élevé, CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:L) et a corrigé dans les versions 10.4.18, 11.2.9, 11.3.6, 11.4.4, 11.5.4, 11.6.1 et 12.0.0 (builds +security-01). Avec le plugin Grafana Image Renderer installé, la même redirection atteint un SSRF en lecture complète ; la Content-Security-Policy par défaut (connect-src) bloque le XSS dans un déploiement standard. L'analyse du NVD sur le même enregistrement donne 6.1 (Moyen) — la vue de la redirection isolée. CVE-2025-6023 a répété le schéma : une redirection ouverte chaînée avec une traversée de chemin vers un XSS, introduite dans Grafana 11.5.0 et corrigée dans 11.3.8, 11.4.6, 11.5.6, 11.6.3 et 12.0.2 (builds +security-01) (CNA Grafana, CVE-2025-6023, publié le 18 juillet 2025).

CVE-2025-69725 — go-chi RedirectSlashes (CVSS 4.7 Moyen) Le middleware RedirectSlashes de go-chi normalisait les chemins à double slash : GET //evil.com était traité comme un chemin nécessitant normalisation, produisant 302 Location: //evil.com. Les navigateurs résolvent les URLs protocol-relative (//evil.com) en https://evil.com. La faille a été introduite dans chi 5.2.2 ; toute application Go avec RedirectSlashes activé et sans validation du Host était affectée. CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N (CNA MITRE, CVE-2025-69725, publié le 19 février 2026).

CVE-2024-23832 — Mastodon (CVSS 9.8 (NVD)) Ce n'est pas une redirection ouverte, et la faille figure dans cette liste précisément pour cette raison : le défaut de Mastodon est une validation d'origine insuffisante, qui permettait à un attaquant d'usurper et de prendre le contrôle de n'importe quel compte distant (NVD, CVE-2024-23832, publié le 1er février 2024). L'avis de GitHub évalue l'impact de confidentialité Faible ; la métrique primaire du NVD donne 9.8 avec C:H. Deux sources, deux lectures du même enregistrement — c'est pourquoi chaque score cité dans cet article nomme sa source.

CVE-2019-3778 — Spring Security OAuth (CVSS 6.5 Moyen) Le cas d'école de la fuite de code par redirection ouverte : les versions 2.3 avant 2.3.5, 2.2 avant 2.2.4, 2.1 avant 2.1.4 et 2.0 avant 2.0.17 acceptaient un redirect_uri manipulé, ce qui faisait rediriger le user-agent du propriétaire de ressource vers une URI contrôlée par l'attaquant avec le code d'autorisation fuité (NVD, CVE-2019-3778, publié le 7 mars 2019). Le NVD note la fuite 6.5 — ce n'est pas la redirection qui la rend dangereuse, c'est le code qu'elle transmet.

Détection#

Test Manuel#

1. Énumérer les paramètres de redirection : utilisez gf redirect (tomnomnom/gf) contre les données Wayback Machine.
2. Identifier tous les endpoints retournant des réponses 30x — vérifier chaque header Location pour du contenu fourni par l'utilisateur.
3. Soumettre un domaine externe comme valeur du paramètre : https://example.com d'abord, puis votre URL Burp Collaborator ou Interactsh.
4. Pour les flux OAuth : injecter une redirection ouverte dans redirect_uri et observer si le code d'autorisation est ajouté à l'URL forgée avant la redirection.
5. Tester les variantes de bypass dans l'ordre : //attacker.com, \attacker.com, %09https://attacker.com, https://attacker.com@trusted.com, https://trusted.com.attacker.com.
6. Confirmer l'élimination des faux positifs : Location: /dashboard et Location: https://target.com/path ne sont PAS des redirections ouvertes.

Détection Automatisée#

# OpenRedireX — fuzzer async avec 50+ payloads de bypass
echo "https://target.com/login?next=FUZZ" | openredirex -p /path/to/payloads.txt
 
# nuclei — template CVE
nuclei -u https://target.com -t http/cves/2025/CVE-2025-4123.yaml
 
# Dalfox v3+ — mode open-redirect
dalfox url "https://target.com/login?next=1" --open-redirect

BreachVex détecte les redirections ouvertes via des sondes canary out-of-band injectées dans les paramètres de redirection découverts. Un finding confirmé nécessite un header Location 30x contenant le domaine canary, plus une vérification eTLD+1 pour éliminer les faux positifs same-origin.

Prévention#

Allowlist par Hostname Exact (pas par préfixe de chaîne)#

# Flask — BONNE PRATIQUE
from urllib.parse import urlparse
 
ALLOWED_HOSTS = frozenset({"app.example.com", "dashboard.example.com"})
 
def is_safe_redirect(url: str, fallback: str = "/dashboard") -> str:
    if not url:
        return fallback
    # Rejeter les caractères de contrôle
    if any(c in url for c in ["\r", "\n", "\t", "\x00", "\\"]):
        return fallback
    parsed = urlparse(url)
    # Autoriser les URLs relatives commençant par / (pas //)
    if not parsed.netloc and url.startswith("/") and not url.startswith("//"):
        return url
    # Les URLs externes doivent être sur l'allowlist
    if parsed.netloc not in ALLOWED_HOSTS:
        return fallback
    return url

// Express.js — BONNE PRATIQUE
const ALLOWED_HOSTS = new Set(["app.example.com", "dashboard.example.com"]);
 
function isSafeRedirect(url) {
  if (!url) return false;
  if (url.startsWith("/") && !url.startsWith("//")) return true;
  try {
    // Constructeur WHATWG — même parseur que les navigateurs
    const parsed = new URL(url);
    return ALLOWED_HOSTS.has(parsed.hostname);
  } catch {
    return false;
  }
}
 
app.get("/redirect", (req, res) => {
  const next = req.query.next ?? "/home";
  res.redirect(isSafeRedirect(next) ? next : "/home");
});

Token Opaque côté Serveur (Élimine le vecteur d'attaque)#

# Stocker la destination avant la redirection — aucune URL dans le paramètre
import secrets
import redis
 
redis_client = redis.Redis()
 
@app.route("/pre-login")
def pre_login():
    state = secrets.token_urlsafe(32)
    redis_client.set(f"redirect:{state}", "/user/dashboard", ex=300)
    return redirect(f"/login?state={state}")
 
@app.route("/post-login")
def post_login():
    state = request.args.get("state", "")
    raw = redis_client.get(f"redirect:{state}")
    destination = raw.decode() if raw else "/dashboard"
    redis_client.delete(f"redirect:{state}")
    return redirect(destination)

OAuth redirect_uri — Correspondance Exacte Obligatoire#

# MAUVAISE PRATIQUE — correspondance par préfixe (contournable)
def validate_redirect_uri(requested: str, registered: str) -> bool:
    return requested.startswith(registered)
 
# BONNE PRATIQUE — comparaison exacte de chaîne RFC 6749 §3.1.2
def validate_redirect_uri(requested: str, registered: str) -> bool:
    return requested == registered  # Correspondance exacte uniquement

Ressources#

• OWASP Unvalidated Redirects and Forwards Cheat Sheet
• PortSwigger — Open Redirect Labs
• CWE-601 : URL Redirection to Untrusted Site
• HackerOne CWE discovery — CWE-601 (relevé du 15 octobre 2026)
• Khodayari, Glauber & Pellegrino — « Do (Not) Follow the White Rabbit: Challenging the Myth of Harmless Open Redirection », NDSS 2025
• RFC 6749 §3.1.2 — OAuth 2.0 Redirection Endpoint
• NVD — CVE-2019-3778 (redirection ouverte Spring Security OAuth fuitant un code d'autorisation)
• Avis de sécurité Grafana — XSS in Frontend Plugins in Grafana (CVE-2025-4123, 21 mai 2025)
• NVD — CVE-2025-6023 (redirection ouverte Grafana chaînée avec traversée de chemin vers XSS)
• NVD — CVE-2025-69725 (redirection ouverte RedirectSlashes de go-chi/chi)
• NVD — CVE-2024-23832 (validation d'origine insuffisante dans Mastodon)