"Demande bloquée. Cet hôte n’est pas autorisé" : Le guide rapide de la liste blanche de l’en-tête Host pour Vite, Rails, Django, Angular et Next.js

Vous lancez un tunnel, collez l’URL publique dans un navigateur, et au lieu de votre application, vous obtenez une erreur. Dans un projet Vite, on lit Blocked request. This host ("your-name.tunnel.example.com") is not allowed.. Dans Rails, vous obtenez une réponse 403 Forbidden. Dans Django, c’est une 400 Bad Request. Dans le serveur de développement Angular, c’est le message Vite repris. Dans Next.js, votre page peut se charger, mais les requêtes de développement sous /_next/* sont bloquées.

Tout cela n’est pas un bogue du tunnel. Votre serveur de développement a reçu une requête pour un nom d’hôte qu’il n’avait jamais entendu, et il a refusé de répondre. Ce guide est une fiche pratique par framework : le réglage exact, ce qu’il accepte, le comportement par défaut, et comment le configurer en toute sécurité. Il explique aussi pourquoi un sous-domaine de tunnel stable transforme ceci d’un simple souci récurrent à une ligne de configuration unique.

Pourquoi les serveurs de développement vérifient l’en-tête Host

Chaque requête HTTP porte un en-tête Host nommant le site avec lequel le navigateur pense communiquer. Historiquement, de nombreux serveurs de développement l’ignoraient. Cela posait problème à cause du DNS rebinding. Une page web malveillante provenant d’un domaine contrôlé par l’attaquant, le DNS de l’attaquant répond alors par 127.0.0.1, et le navigateur considère désormais votre serveur local comme faisant partie de l’origine de l’attaquant. La page de l’attaquant peut lire tout ce que votre serveur de développement renvoie, y compris le code source.

Vérifier l’en-tête Host par rapport à une liste blanche ferme cette porte, car le domaine de l’attaquant n’est pas sur la liste. Rails décrit son middleware comme une protection contre le DNS rebinding. La documentation de Vite affirme que laisser la vérification ouverte permet à n’importe quel site de télécharger votre code source et votre contenu via DNS rebinding.

Le coût est qu’un nom d’hôte de tunnel légitime peut aussi être « inconnu » jusqu’à ce que vous l’ajoutiez à la liste.

Un détail spécifique à Vite compte pour les tunnels. La vérification de l’hôte est ignorée lorsque le serveur de développement lui-même sert du HTTPS. Beaucoup de tunnels terminent TLS à leur edge et transmettent du HTTP en clair à votre machine; dans ce cadre, la vérification s’applique toujours.

Diagnostic rapide : quelle couche vous refuse l’accès ?

Cadre	Réglage	Ce que vous voyez
Vite	server.allowedHosts	403 avec le message Blocked request. This host (...) is not allowed.
Rails	config.hosts	403 Forbidden ; une page de débogage en développement, un corps vide sinon ; une ligne Blocked hosts: dans les logs
Django	ALLOWED_HOSTS	DisallowedHost (un SuspiciousOperation), retourné comme 400 Bad Request
Angular (serveur de dev)	allowedHosts dans angular.json	Le même message que Vite
Next.js	allowedDevOrigins	La page peut s’afficher, mais des ressources de dev telles que /_next/webpack-hmr sont bloquées, avec un avertissement Blocked cross-origin request to Next.js dev resource dans le terminal

Une règle utile : si le texte d’erreur indique l’hôte et précise quoi ajouter, la requête a bien atteint votre framework et le tunnel fonctionne. Vous êtes en train de corriger une configuration, pas le réseau.

Sémantiques génériques à connaître

Les notions de wildcard varient selon les frameworks, et c’est souvent là que surviennent les surprises.

Cadre	Syntaxe	Correspond au domaine nu ?	Correspond aux sous-domaines imbriqués ?
Vite	.example.com	Oui	Oui (toute profondeur, selon la doc)
Rails	.example.com	Oui	Un seul label dans le code courant ; les versions plus anciennes étaient plus lâches
Django	.example.com	Oui	Oui (« tout autre sous-domaine »)
Next.js	*.example.com	Non	Non (exactement un label)
Next.js	**.example.com	Non	Oui (un ou plusieurs labels)
Angular dev server	identique à Vite	Oui	Oui

Quoi que vous utilisiez, testez un vrai nom d’hôte de tunnel avant de supposer qu’un motif fonctionne.

Vite : server.allowedHosts

Vite documente server.allowedHosts comme string[] | true, par défaut []. Par défaut, il accepte localhost, tout domaine sous .localhost, et toutes les adresses IP. Tout le reste renvoie une 403.

La vérification est arrivée avec la correction pour l’avis GHSA-vg6x-rcgg-rjx6 (CVE-2025-24010). Le journal des versions 6.0.9 liste une vérification de l’en-tête Host qui a introduit server.allowedHosts. Les versions corrigées sont 6.0.9, 5.4.12 et 4.5.6. C’est pourquoi les mises à jour déclenchent souvent l’erreur sur des configurations qui fonctionnaient pendant des mois.

// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  server: {
    allowedHosts: ['my-app.tunnel.example.com'],
  },
})

Un point à connaître :

• Point initial (Leading dot). Une chaîne qui commence par . autorise cet hôte sans le point, ainsi que tous ses sous-domaines. Selon la doc, .example.com couvre example.com, foo.example.com et foo.bar.example.com. N’appliquez ceci qu’à un domaine que vous possédez.
• N’ajoutez jamais un domaine de niveau supérieur tel que .com. La doc avertit que n’importe qui peut enregistrer un domaine et contrôler où il résout.
• Variable d’environnement. Définir __VITE_ADDITIONAL_SERVER_ALLOWED_HOSTS ajoute des hôtes sans toucher au fichier de config. Séparez plusieurs hôtes par des virgules.
• vite preview est séparé. Le serveur de prévisualisation a son propre preview.allowedHosts. Par défaut, il prend la valeur de server.allowedHosts, il faut donc le définir explicitement si les deux doivent différer.
• Paramètre associé : server.cors. La même recommandation a changé la gestion CORS de Vite. Par défaut, seules les origines de type localhost sont autorisées ; la doc indique que server.cors: true permet le téléchargement du code source par n’importe quel site.
• Frameworks basés sur Vite. Nuxt prend l’option sous vite.server.allowedHosts dans nuxt.config.ts. L’admin Strapi s’exécute aussi sur Vite. La note de Strapi indique que la config de développement définit désormais allowedHosts: true en interne, si vous utilisez une version récente, la mise à niveau peut suffire. Si vous voyez « edit vite.config.js » mais que vous n’avez aucun fichier, cherchez une clé vite dans la config de votre framework.

Si la page se charge mais que le rechargement à chaud est cassé. Autoriser l’hôte résout le chargement initial, mais le remplacement de module en temps réel utilise un WebSocket. Les tunnels qui réécrivent les ports peuvent le casser, et le guide de Strapi signale cela pour ngrok, Cloudflare Tunnel et les forwards de port VS Code. Les docs de Vite listent les réglages WebSocket sous server.ws, y compris clientPort, qui peut surcharger le port vers lequel le navigateur se connecte. Dans les versions plus anciennes, les options WebSocket server.hmr restent visibles mais dépréciées au profit de server.ws. Sur les anciennes versions, vous les trouverez encore dans server.hmr.

L’astuce souvent repérée sur les forums est allowedHosts: true. Nous reviendrons sur pourquoi c’est une mauvaise valeur par défaut.

Rails : config.hosts

Rails appelle cela l’Host Authorization, mis en œuvre par ActionDispatch::HostAuthorization. En développement, la liste blanche par défaut est .localhost, .test, et chaque adresse IPv4 et IPv6. Dans d’autres environnements, config.hosts est vide par défaut. Quand il est vide, le middleware ne fait rien, donc la vérification n’intervient qu’en développement ou lorsque vous avez configuré les hôtes vous-même.

# config/environments/development.rb
config.hosts << "my-app.tunnel.example.com"

Ce que la source indique :

• Chaînes correspondent à l’hôte avec éventuellement un port. Une chaîne qui commence par un point (par exemple .example.com) correspond au domaine racine et à un sous-domaine. Dans le code courant, cela correspond à un label optionnel ; testez les noms imbriqués comme a.b.example.com avant de supposer qu’ils passent. Les versions plus anciennes utilisaient un motif plus laxiste, donc le comportement peut varier selon les versions de Rails.
• Regex, plages d’IP et lambdas sont acceptés. Les entrées sont comparées avec ===, ce qui permet des vérifications dynamiques via une lambda. Les chaînes et les expressions régulières gèrent le port et le traitement du leading-dot, et une lambda ne le fait pas.
• X-Forwarded-Host est vérifié aussi. Le middleware bloque une requête si soit le Host, soit la dernière valeur X-Forwarded-Host n’est pas autorisée, ce qui importe lorsqu’un proxy se trouve devant.
• Opt-out par route. config.host_authorization = { exclude: (request) => (request.path =~ /healthcheck/) } évite la vérification pour les requêtes correspondantes, comme les probes de santé du load-balancer.
• La réponse est 403 Forbidden, et les hôtes bloqués sont consignés au niveau error. Le corps peut contenir des infos de débogage uniquement si config.consider_all_requests_local est vrai. Sinon il est vide, ce qui peut faire passer des blocs en production pour un mystère.
• Garder Rails à jour. Les entrées qui commencent par un point et les en-têtes X-Forwarded-Host ont été l’objet d’avis de sécurité passés, y compris CVE-2021-22881.

Comme un config.hosts vide désactive la vérification, config.hosts.clear est l’équivalent Rails de true chez Vite. Traitez-le de la même façon.

Django : ALLOWED_HOSTS

Django a introduit ALLOWED_HOSTS dans les versions 1.4.4 (février 2013) comme une correction de sécurité pour l’empoisonnement de l’en-tête Host. En 1.4.4, la valeur par défaut était ['*'] pour la compatibilité. Aujourd’hui, la valeur par défaut est une liste vide.

Avec DEBUG = False, une liste vide fait échouer chaque requête avec Bad Request (400). Avec DEBUG = True et une liste vide, la doc indique que l’hôte est validé contre ['.localhost', '127.0.0.1', '[::1]'], de sorte qu’un nom d’hôte de tunnel échoue même en mode debug.

Cette pratique a son histoire. Les versions plus anciennes contournaient la vérification sous DEBUG=True, ce qui permettait des attaques de DNS rebinding (CVE-2016-9014). Django l’a corrigé dans les versions 1.10.3, 1.9.11 et 1.8.16.

# settings.py
ALLOWED_HOSTS = ["my-app.tunnel.example.com"]

• Correspondance exacte. Les noms sont comparés au Host header sans tenir compte du port et sans distinction de casse. Un point terminal (forme FQDN) est retiré avant comparaison.
• Leading period comme wildcard. .example.com correspond à example.com, www.example.com et tout autre sous-domaine. La docs décrit seulement deux formes de wildcard: le point initial et un * nu (tout). Elles ne documentent pas *.example.com.
• USE_X_FORWARDED_HOST. Si activé, Django valide X-Forwarded-Host au lieu de Host.
• Contournement d’avertissement. La validation se fait dans get_host(). Le code qui lit l’en-tête à partir de request.META le saute directement.

Un piège adjacent : une fois la page chargée via le tunnel, les posts de formulaire peuvent encore échouer la vérification CSRF d’origine de Django. L’origine du navigateur est l’URL https:// du tunnel, et Django doit accepter cela. Ajoutez l’origine complète, y compris le schéma, à CSRF_TRUSTED_ORIGINS. Cette configuration prend en charge les wildcard de sous-domaines comme https://*.example.com. Si votre tunnel transmet du HTTP non chiffré, vérifiez aussi que SECURE_PROXY_SSL_HEADER convient. Activez-le uniquement si le proxy contrôle de manière fiable l’en-tête X-Forwarded-Proto.

Angular : allowedHosts dans angular.json

Le serveur de développement moderne d’Angular tourne sur Vite, vous obtenez donc l’erreur de Vite, mais il n’y a pas de fichier vite.config.js à modifier. Le CLI Angular a ajouté une option de serveur-dev allowedHosts (PR #29466, janvier 2025) après être passé à Vite 6.0.9 ou plus. La doc du CLI décrit cela comme les hôtes auxquels le serveur-dev répond, et dit que cela corresponde à l’option Vite du même nom.

"serve": {
  "builder": "@angular/build:dev-server",
  "options": {
    "allowedHosts": ["my-app.tunnel.example.com"]
  }
}

Le constructeur basé sur webpack (@angular-devkit/build-angular:dev-server) prend la même option au même endroit. Les tests du CLI confirment trois comportements: un hôte listé passe, true autorise n’importe quel hôte, et un tableau vide rejette les hôtes inconnus. Le CLI expose aussi le réglage comme --allowed-hosts.

Angular expose aussi une seconde vérification d’hôte, non liée à la première. Il faut donc distinguer : la validation côté serveur SSRF n’emploie pas la même formulation que le message Vite. Les messages ci-dessous reflètent cela :

• Host http://localhost:4200/ is not allowed. You can configure allowedHosts option.
• URL with hostname "..." is not allowed. Please provide a list of allowed hosts in the "allowedHosts" option in the "CommonEngine" constructor.

Pour SSR, allowedHosts peut être défini dans le constructeur CommonEngine, dans les options de build dans angular.json, ou via la variable d’environnement NG_ALLOWED_HOSTS. Les rapporteurs ont utilisé cette variable pour résoudre le cas localhost. Une remarque signalait que l’option accepte des noms d’hôtes exacts ou un préfixe wildcard tel que *.domain, et non des motifs arbitraires. Si votre texte d’erreur diffère de la phrase Vite, vous êtes dans cette seconde couche, et modifier serve.options ne suffira pas.

La liste d’accès SSR a elle-même été patchée. CVE-2026-50168 (GHSA-xrxm-cp7j-8xf6) est une contournement de la liste d’accès dans @angular/platform-server, corrigé dans 22.0.0-rc.2, 21.2.15, 20.3.22 et 19.2.23. Si vous dépendez de la validation d’hôte SSR, restez sur une version corrigée.

Next.js : allowedDevOrigins

Next.js se distingue d’une façon importante : ce n’est pas une liste blanche avec le header Host. Il bloque les requêtes cross-origin vers les ressources et endpoints dédiés au dev. Il ne correspond qu’au nom d’hôte de l’en-tête Origin de la requête, en revenant au nom d’hôte du Referer pour les requêtes no-cors (telles que les balises script). Le schéma, le port et le chemin sont ignorés, écrivez donc les entrées sans https:// et sans port.

// next.config.js
module.exports = {
  allowedDevOrigins: ['my-app.tunnel.example.com'],
}

Le serveur de dev autorise déjà localhost, ses sous-domaines, et le nom d’hôte à partir duquel il a été lancé. Tout autre nom d’hôte nécessite une entrée. Les docs officiels utilisent un tunnel comme exemple d’un nom d’hôte nécessitant une entrée.

Les wildcards sont plus strictes qu’on ne le pense :

Entrée	Correspond	Ne correspond pas
my.dev	my.dev	team.my.dev
*.my.dev	team.my.dev	my.dev, team.eu.my.dev
**.my.dev	team.my.dev, team.eu.my.dev	my.dev

* signifie exactement un label et ** un ou plusieurs, mais ** ne peut apparaître qu’au début d’un motif. Comme aucun wildcard ne correspond au domaine nu, listez l’apex séparément si nécessaire.

L’option a une histoire qui explique pourquoi les anciens messages diffèrent. Elle est arrivée avec la correction de sécurité CVE-2025-48068 dans Next.js 15.2.2 et 14.2.30. L’avis décrit la correction comme une option qui nécessite de configurer allowedDevOrigins, et les versions précoces ne faisaient que avertir. Une modification intégrée en mars 2026 a retiré l’avertissement par défaut et mis le bloc en défaut, et la doc actuelle décrit cela ainsi. Si vous utilisez une version plus ancienne, les docs de votre version s’appliquent.

Si votre page se charge via un tunnel mais que le comportement interactif se dégrade, et le terminal affiche un avertissement Blocked cross-origin request to Next.js dev resource, c’est votre réglage. Gardez Next.js à jour aussi. CVE-2026-27977 permettait à Origin: null de contourner la protection WebSocket dans next dev de 16.0.1 jusqu’au correctif en 16.1.7, même lorsque allowedDevOrigins était configuré.

Pourquoi un sous-domaine stable mérite de le configurer une seule fois

Les listes autorisées sont exactes par conception, donc le vrai coût dépend de la fréquence à laquelle votre nom d’hôte public change.

Avec un tunnel jetable qui délivre un nom d’hôte aléatoire à chaque démarrage, vous modifiez la liste autorisée à chaque session. Chaque édition génère aussi une modification de fichier de config qui peut être commise, et chaque collègue a un nom différent. Cette fatigue est ce qui amène allowedHosts: true dans les dépôts.

Avec un sous-domaine réservé et stable, le nom d’hôte est connu avant même de démarrer le tunnel. Vous ajoutez my-app.tunnel.example.com à la liste autorisée une fois, vous le validez dans le dépôt, et chaque collègue, chaque exécution CI et chaque prestataire de webhook pointe vers le même nom. L’erreur avec laquelle vous avez commencé cet article cesse tout simplement de se produire. La même stabilité profite à tout ce qui dépend du nom d’hôte : les URIs de redirection OAuth, les points de terminaison des webhooks, les origines CSRF approuvées et les signets sauvegardés.

Si un nom d’hôte est personnel plutôt que partagé, gardez-le hors du dépôt et lisez-le à partir d’une variable d’environnement à la place :

// vite.config.js
server: {
  allowedHosts: process.env.TUNNEL_HOST ? [process.env.TUNNEL_HOST] : [],
}

# config/environments/development.rb
config.hosts << ENV["TUNNEL_HOST"] if ENV["TUNNEL_HOST"]

La même approche fonctionne dans settings.py avec os.environ et dans next.config.js avec process.env.

Le piège allowedHosts: true

Désactiver la vérification est une ligne dans chaque framework ci-dessus : true pour Vite, config.hosts.clear pour Rails, ALLOWED_HOSTS pour Django, ou true dans l’option du serveur-dev Angular. Cela « corrige » l’erreur immédiatement, ce qui explique sa propagation.

La documentation de Vite est claire : définir server.allowedHosts sur true autorise n’importe quel site à envoyer des requêtes à votre serveur de développement via DNS rebinding, ce qui permet de télécharger votre code source et votre contenu. Elle recommande toujours d’utiliser une liste explicite. Vous avez désactivé le seul contrôle existant pour empêcher cela.

Deux erreurs associées sont faciles à commettre lorsque l’on essaie d’être prudent :

1. Autoriser un suffixe partagé. Ajouter le domaine partagé d’un fournisseur de tunnel, comme .ngrok-free.app, à la liste étend la confiance à un domaine que vous ne contrôlez pas. La recommandation est d’ajouter uniquement des hôtes dont vous contrôlez la résolution, ou dont vous pouvez faire confiance au propriétaire.
2. Tout autoriser « juste pour la démo ». Les serveurs de développement accompagnent les démonstrations et dépassent les sessions. Conservez l’hôte explicite à la place.

Une checklist pratique

1. Lisez l’erreur. Si elle nomme l’hôte et le réglage à modifier, corrigez la configuration, pas le tunnel.
2. Copiez l’hôte exact depuis l’URL publique, sans le schéma ni le port.
3. Ajoutez-le au bon endroit : server.allowedHosts, config.hosts, ALLOWED_HOSTS, allowedHosts dans angular.json, ou allowedDevOrigins.
4. Redémarrez le serveur de développement. Les paramètres de fichier de config se lisent normalement au démarrage.
5. Si la page se charge mais que le rechargement à chaud ou les posts de formulaire échouent, vérifiez les paramètres WebSocket (Vite), CSRF_TRUSTED_ORIGINS (Django), ou les avertissements “dev-resource” (Next.js).
6. Réservez un sous-domaine stable afin que ce soit la dernière fois que vous l’éditerez.
7. Vérifiez depuis l’extérieur de votre réseau, par exemple sur un téléphone en données cellulaires, pas seulement sur votre machine.
8. Ne Commitez jamais true, '*' ou un suffixe de fournisseur partagé.

FAQ

Pourquoi mon app fonctionne sur localhost mais pas via un tunnel ?

Sur localhost, l’en-tête Host est localhost, ce que tous les frameworks ci-dessus autorisent par défaut. Via un tunnel, c’est le nom d’hôte public qui n’est pas sur les listes par défaut.

allowedHosts: true est-il jamais acceptable ?

Uniquement sur une machine et un réseau que vous contrôlez entièrement, pour une courte durée, sans données sensibles dans le projet. Même dans ce cas, un nom d’hôte explicite coûte une ligne et évite le risque.

Dois-je autoriser le port aussi ?

Non. Django correspond les hôtes sans le port, Rails tolère un port optionnel, et les entrées Next.js doivent être écrites sans port.

L’erreur mentionne vite.config.js mais mon framework n’en a pas. Que faire ?

Cherchez une clé de passage : vite.server.allowedHosts dans Nuxt, la config Vite d’administration dans Strapi (ou mettez Strapi à jour), et allowedHosts dans angular.json pour Angular.

Est-ce que cela affecte la production ?

Ce sont des réglages du dev-server pour Vite, Angular et Next.js. Django et Rails s’appliquent aussi selon le contexte. Django’s ALLOWED_HOSTS s’applique en production, et Rails’ config.hosts s’applique dans tout environnement où vous le configurez.

Références

• Vite, Server Options et Preview Options
• Avis Vite GHSA-vg6x-rcgg-rjx6
• Rails API, ActionDispatch::HostAuthorization et pull request #33145
• Django, Settings: ALLOWED_HOSTS et CSRF_TRUSTED_ORIGINS, 1.4.4 release notes et 2016 security releases
• Angular CLI, ng serve options, [pull request #29466], [issue #33184] et [issue #32616]
• Angular advisory GHSA-xrxm-cp7j-8xf6
• Next.js, allowedDevOrigins, [advisory GHSA-3h52-269p-cp9r], [pull request #91507] et [CVE-2026-27977]
• Strapi, Fixing “Blocked request. This host is not allowed” in Strapi 5
• Nuxt example, Fixing ‘Blocked request’ When Exposing a Nuxt 3 Dev Server Through ngrok