„Blockierte Anfrage. Dieser Host ist nicht zulässig“: Die Checkliste zur Host-Header-Allowlist für Vite, Rails, Django, Angular und Next.js

Du startest einen Tunnel, fügst die öffentliche URL in einen Browser ein, und statt deiner Anwendung erhältst du eine klare Fehlermeldung. In einem Vite-Projekt lautet sie Blocked request. This host ("your-name.tunnel.example.com") is not allowed. In Rails bekommst du eine 403 Forbidden-Antwort. In Django ist es eine 400 Bad Request. Im Angular-Entwicklungsserver ist es wieder die Vite-Meldung. In Next.js kann deine Seite laden, aber dev-only Anfragen unter /_next/* werden blockiert.

Nichts davon ist ein Fehler des Tunnels. Dein Dev-Server hat eine Anfrage für einen Hostnamen erhalten, den er noch nie gehört hat, und weigerte sich zu antworten. Diese Anleitung ist eine Framework-spezifische Checkliste: die genaue Einstellung, was sie akzeptiert, was der Standard ist und wie man sie sicher konfiguriert. Sie erklärt auch, warum eine stabile Tunnel-Subdomain dies von einer wiederkehrenden Belästigung in eine einmalige Konfigurationszeile verwandelt.

Warum Dev-Server überhaupt den Host-Header prüfen

Jede HTTP-Anfrage trägt einen Host-Header, der die Site benennt, mit der der Browser zu kommunizieren glaubt. Historisch ignorierten viele Dev-Server ihn. Das wurde zu einem Problem wegen DNS-Rebinding. Eine bösartige Webseite lädt von einer Angreifer-verwalteten Domain, der DNS des Angreifers antwortet dann mit 127.0.0.1, und der Browser behandelt nun deinen lokalen Server als Teil des Ursprungs des Angreifers. Die Angreiferseite kann alles auslesen, was dein Dev-Server zurückgibt, einschließlich Quellcode.

Die Prüfung des Host-Headers gegen eine Allowlist schließt diese Tür, weil die Domäne des Angreifers nicht auf der Liste steht. Rails beschreibt seine Middleware als Schutz gegen DNS-Rebinding. Die Dokumentation von Vite besagt, dass eine offene Prüfung es jeder Website ermöglicht, deinen Quellcode und Inhalt durch DNS-Rebinding herunterzuladen.

Die Folge ist, dass ein legitimer Tunnel-Hostname ebenfalls als „unbekannt“ gilt, bis du ihn in der Liste führst.

Ein vites-spezifisches Detail ist wichtig für Tunnels. Die Host-Check von Vite wird übersprungen, wenn der Dev-Server selbst HTTPS bereitstellt. Viele Tunnels beenden TLS am Edge und leiten reines HTTP an deine Maschine weiter, und in diesem Setup gilt die Prüfung weiterhin.

Schnelle Diagnose: Welche Ebene lehnt dich ab?

Framework	Einstellung	Was du siehst
Vite	server.allowedHosts	403 mit Blocked request. This host (...) is not allowed.
Rails	config.hosts	403 Forbidden; eine Debug-Seite in der Entwicklung, ansonsten ein leerer Body; eine Blocked hosts:-Zeile im Log
Django	ALLOWED_HOSTS	DisallowedHost (ein SuspiciousOperation), zurückgegeben als 400 Bad Request
Angular (Dev-Server)	allowedHosts in angular.json	Die gleiche Vite-Meldung
Next.js	allowedDevOrigins	Die Seite kann gerendert werden, aber Dev-Ressourcen wie /_next/webpack-hmr werden blockiert, mit einer Warnung im Terminal: Blocked cross-origin request to Next.js dev resource

Eine nützliche Regel: Wenn der Fehlertitel den Host benennt und angibt, was du hinzufügen sollst, hat die Anfrage dein Framework erreicht und der Tunnel funktioniert. Du behebst die Konfiguration, nicht das Networking.

Wildcard-Semantik auf einen Blick

Die Frameworks sind uneinig darüber, was ein „Wildcard“ bedeutet, und genau daraus entstehen die meisten Überraschungen.

Framework	Syntax	Passt die Basendomain?	Passt verschachtelte Subdomains?
Vite	.example.com	Ja	Ja (jede Tiefe, laut Dokumentation)
Rails	.example.com	Ja	Ein Label im aktuellen Quellcode; ältere Versionen waren lockerer
Django	.example.com	Ja	Ja („jede andere Subdomain“)
Next.js	*.example.com	Nein	Nein (genau ein Label)
Next.js	**.example.com	Nein	Ja (ein oder mehrere Labels)
Angular dev server	wie bei Vite	Ja	Ja

Welchen davon auch immer du verwendest, teste einen echten Tunnel-Hostname, bevor du annimmst, dass ein Muster funktioniert.

Vite: server.allowedHosts

Vite dokumentiert server.allowedHosts als string[] | true und standardmäßig als []. Standardmäßig akzeptiert es localhost, jede Domain unter .localhost und alle IP-Adressen. Alles andere erhält eine 403.

Die Prüfung kam mit der Behebung des Advisory GHSA-vg6x-rcgg-rjx6 (CVE-2025-24010). Das Changelog von 6.0.9 listet eine Host-Header-Prüfung auf, die server.allowedHosts eingeführt hat. Die advisories wurden auf Versionen 6.0.9, 5.4.12 und 4.5.6 behoben. Deshalb lösen Upgrades oft den Fehler in Setups aus, die Monate lang funktioniert haben.

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

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

Ein paar Details, die es wert sind zu wissen:

• Führende Punkt. Eine Zeichenkette, die mit . beginnt, erlaubt diesen Hostnamen ohne den Punkt und alle seine Subdomains. Laut der Dokumentation deckt .example.com example.com, foo.example.com und foo.bar.example.com ab. Tu das nur für eine Domain, die du besitzt.
• Niemals eine Top-Level-Domain hinzufügen wie .com. Die Dokumentation warnt, dass jeder eine Domain registrieren und auf sie auflösen kann.
• Umgebungsvariable. Das Setzen von __VITE_ADDITIONAL_SERVER_ALLOWED_HOSTS fügt Hosts hinzu, ohne die Config-Datei zu ändern. Mehrere Hosts mit Kommas trennen. Das ist praktisch in CI oder in einem gemeinsamen Repo, in dem du keinen persönlichen Tunnel-Namen festschreiben möchtest.
• vite preview ist separat. Der Vorschau-Server hat seine eigene preview.allowedHosts. Er übernimmt standardmäßig den Wert von server.allowedHosts, daher lege ihn explizit fest, nur falls sich die beiden unterscheiden sollen. Lies den Fehlertext, um zu sehen, auf welchen Block er zeigt.
• Verwandte Einstellung: server.cors. Die gleiche Advisories hat Vites CORS-Verhalten geändert. Die Standardoption erlaubt jetzt nur origins im localhost-Stil, und die Dokumentation warnt, dass server.cors: true jede Website herunterladen lässt.
• Frameworks, die auf Vite basieren. Nuxt nutzt die Option unter vite.server.allowedHosts in nuxt.config.ts. Strapi 5s Admin-Panel läuft auch auf Vite. Strapis eigener Beitrag sagt, dass die Entwicklungs-Konfiguration jetzt intern allowedHosts: true setzt, sodass bei einem aktuellen Release Strapi-Upgrade die Lösung sein kann. Wenn du “edit vite.config.js” siehst, aber keine solche Datei hast, suche nach einem vite-Schlüssel in der Framework-Konfiguration.

Wenn die Seite lädt, aber das Hot-Reload versagt. Die Host-Konfiguration behebt das Laden der Seite, aber WebSocket-basiertes HMR kann Probleme verursachen. Tunnels, die Ports neu schreiben, können es unterbrechen. Strapi verweist in seiner Anleitung auf ngrok, Cloudflare Tunnel und VS Code Port-Forwarding. Die WebSocket-Einstellungen listet die Vite-Dokumentation unter server.ws auf, einschließlich clientPort, der den Port bestimmt, zu dem der Browser verbindet. In älteren Vite-Versionen findest du sie noch unter server.hmr.

Der Shortcut, den du in Foren finden wirst, ist allowedHosts: true. Wir schauen gleich, warum das ein schlechter Standard ist.

Rails: config.hosts

Rails nennt das Host-Autorisierung, implementiert von ActionDispatch::HostAuthorization. In der Entwicklung ist die Standard-Allowlist .localhost, .test und jede IPv4- und IPv6-Adresse. In anderen Umgebungen ist config.hosts standardmäßig leer. Wenn es leer ist, tut die Middleware nichts, sodass die Prüfung nur in der Entwicklung oder wenn du Hosts selbst konfiguriert hast greift.

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

Was der Quellcode dir sagt:

• Strings stimmen mit dem Host ab, wahlweise mit Port. Ein String, der mit einem Punkt beginnt (wie .example.com), passt zur Apex-Domain plus Subdomain. In aktueller Quelle ist das ein optionales Label ([a-z0-9-]+\\.), teste also verschachtelte Namen wie a.b.example.com bevor du annimmst, dass sie durchkommen. Ältere Versionen verwendeten ein weiter gefasstes Muster, daher kann das Verhalten zwischen Rails-Versionen variieren.
• Regex, IP-Bereiche und Lambdas werden akzeptiert. Einträge werden mit === verglichen, daher gibt dir eine Lambda dynamische Checks. Strings und Regexes erhalten die Port- und Leading-Dot-Handhabung, und eine Lambda tut dies nicht.
• X-Forwarded-Host wird auch geprüft. Die Middleware blockiert eine Anfrage, wenn entweder Host oder der letzte X-Forwarded-Host-Wert nicht erlaubt ist, was wichtig ist, wenn ein Proxy davor sitzt.
• Opting out per route. config.host_authorization = { exclude: (request) => { request.path =~ /healthcheck/ } } überspringt die Prüfung für passende Anfragen, z. B. Health-Probes von Load-Balancern.
• Die Antwort ist 403 Forbidden, und die geblockten Hosts werden auf Log-Ebene error protokolliert. Der Body enthält Debug-Infos nur, wenn config.consider_all_requests_local true ist. Andernfalls ist er leer, was Produktionsblocks wie ein Rätsel aussehen lässt.
• Rails gepatched halten. Leading-dot-Einträge kombiniert mit formulierten X-Forwarded-Host-Headern waren Gegenstand vergangener Advisories, einschließlich CVE-2021-22881.

Weil ein leeres config.hosts die Prüfung deaktiviert, ist config.hosts.clear das Rails-Äquivalent von Vite’s true. Behandle es genauso.

Django: ALLOWED_HOSTS

Django führte ALLOWED_HOSTS in 1.4.4 (16. Februar 2013) als Sicherheitsmaßnahme gegen Host-Header-Poisoning ein. In 1.4.4 war der Standard ['*'] für Abwärtskompatibilität. Heute ist der Standard eine leere Liste.

Mit DEBUG = False führt eine leere Liste dazu, dass jede Anfrage mit Bad Request (400) fehlschlägt. Mit DEBUG = True und einer leeren Liste gibt die aktuelle Dokumentation an, dass der Host gegen ['.localhost', '127.0.0.1', '[::1]'] validiert wird, sodass ein Tunnel-Host auch im Debug-Modus fehlschlägt.

Diese Debug-Verhalten hat seine eigene Geschichte. Ältere Versionen überspringen die Prüfung bei DEBUG=True, was DNS-Rebinding-Angriffe ermöglichte (CVE-2016-9014). Django hat es in 1.10.3, 1.9.11 und 1.8.16 behoben.

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

• Exakter Abgleich. Namen werden gegenüber dem Host-Header groß-/kleinfallend verglichen, ohne Port. Eine abschließende Punktform (FQDN) wird vor dem Vergleich entfernt.
• Leading period als Platzhalter. .example.com passt zu example.com, www.example.com und jeder anderen Subdomain. Die Dokumentation beschreibt genau zwei Wildcard-Formen, den führenden Punkt und einen bloßen * (alles). *.example.com wird nicht dokumentiert.
• USE_X_FORWARDED_HOST. Falls aktiviert, validiert Django X-Forwarded-Host statt Host.
• Umgehungshinweis. Die Validierung erfolgt in get_host(). Code, der den Header direkt aus request.META liest, überspringt ihn.

Ein weiteres Achtung: Sobald die Seite durch den Tunnel geladen ist, können Formular-Posts Django’s CSRF-Origin-Check immer noch fehlschlagen. Der Browser-Origin ist die URL des Tunnels, und Django muss zustimmen. Füge den vollständigen Ursprung, einschließlich des Schemas, zu CSRF_TRUSTED_ORIGINS hinzu. Diese Einstellung unterstützt Subdomain-Wildcards wie https://*.example.com. Falls dein Tunnel plain HTTP weiterleitet, überprüfe außerdem, ob SECURE_PROXY_SSL_HEADER sinnvoll ist. Setze es nur, wenn der Proxy zuverlässig den X-Forwarded-Proto-Header kontrolliert.

Angular: allowedHosts in angular.json

Angulas moderner Dev-Server läuft auf Vite, daher erhältst du Vite’s Fehler, aber es gibt keine vite.config.js zum Bearbeiten. Die Angular CLI hat eine Dev-Server‑Option allowedHosts (Pull Request #29466, Januar 2025) nach dem Umstieg auf Vite 6.0.9 oder später hinzugefügt. Die CLI-Dokumentation beschreibt es als die Hosts, auf die der Dev-Server reagieren wird, und sagt, dass es die Vite-Option mit demselben Namen setzt.

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

Der webpack-basierte Builder (@angular-devkit/build-angular:dev-server) übernimmt dieselbe Option an derselben Stelle. Die CLI selbst testet drei Verhaltensweisen: ein gelisteter Host klappt, true erlaubt jeden Host und ein leeres Array lehnt unbekannte Hosts ab. Die CLI bietet die Einstellung auch als --allowed-hosts an.

Angular hat eine zweite, unabhängige Host-Überprüfung, und es ist leicht, sie mit der ersten zu verwechseln. Serverseitige Validierung bestätigt den Anfrageshostnamen als SSRF-Abwehr, und ihre Meldungen verwenden nicht die Vite‑Worte:

• Host http://localhost:4200/ is not allowed. You can configure allowedHosts option. Entwickler meldeten dies in ng serve für SSR-Projekte nach Patch Release 19.2.22 (Issue #33184).
• URL with hostname "..." is not allowed. Please provide a list of allowed hosts in the "allowedHosts" option in the "CommonEngine" constructor. Entwickler berichteten dies nach @angular/ssr 21.1.5. Sie sahen es hinter einem Load Balancer, wo der Validator eine interne IP statt des öffentlichen Namens sah (Issue #32616).

Für SSR kann allowedHosts im CommonEngine-Konstruktor gesetzt werden, in Build-Optionen in angular.json oder über die NG_ALLOWED_HOSTS-Umgebungsvariable. Reporter nutzten die Umgebungsvariable, um den localhost‑Fall zu lösen. Ein Reporter merkte an, dass die Option genaue Hostnamen oder ein Wildcard-Präfix wie *.domain akzeptiert, nicht willkürliche Muster. Wenn dein Fehlertext vom Vite-Satz abweicht, bist du in dieser zweiten Schicht, und das Ändern von serve.options behebt es nicht.

Der SSR-Whitelist ist selbst gepatcht worden. CVE-2026-50168 (GHSA-xrxm-cp7j-8xf6) ist eine Whitelist-Umgehung in @angular/platform-server, behoben in 22.0.0-rc.2, 21.2.15, 20.3.22 und 19.2.23. Wenn du auf einer älteren Version bist, gelten die Docs deiner Version.

Next.js: allowedDevOrigins

Next.js unterscheidet sich in einer wichtigen Weise: Es ist keine Host-Header-Whitelist. Es blockiert Cross-Origin-Anfragen zu Dev-only Ressourcen und Endpunkten. Es stimmt nur mit dem Hostnamen des Origin-Headers der Anfrage überein, und fällt bei No-CORS-Anfragen wie Skript-Tags zurück auf den Hostnamen des Referers. Schema, Port und Pfad werden ignoriert, also Einträge ohne https:// und ohne Port schreiben.

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

Der Dev-Server erlaubt bereits localhost, seine Subdomains und den gestarteten Hostnamen. Jeder andere Hostname braucht einen Eintrag. Die offizielle Dokumentation verwendet einen Tunnel als Beispiel für einen Host, der einen braucht.

Wildcard-Einträge sind strenger als man erwarten würde:

Eintrag	Übereinstimmung	Nicht übereinstimmend
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

* steht für genau ein Label und ** für eins oder mehrere. ** funktioniert nur am Anfang eines Musters, und Teilersatz wie team-*.my.dev wird nicht unterstützt. Da keines der Wildcards die bare Domain trifft, liste den Apex separat, wenn du ihn benötigst.

Die Option hat eine kurze Geschichte, die erklärt, warum frühere Beiträge widersprechen. Sie kam mit dem Sicherheitshinweis zu CVE-2025-48068 in Next.js 15.2.2 und 14.2.30. Die Advisories beschreiben die Behebung als eine aktive Wahl, die dich dazu zwingt, allowedDevOrigins zu konfigurieren, und frühere Versionen hatten nur Warnungen. Eine im März 2026 zusammengeführte Änderung (Pull Request #91507) entfernte die standardmäßig warnende Variante und setzte standardmäßig Blockieren, und die aktuellen Docs beschreiben es so. Wenn du eine ältere Version hast, gelten die Docs deiner Version.

Wenn deine Seite durch einen Tunnel rendert, interaktives Verhalten jedoch bricht, und das Terminal eine Warnung zeigt Blocked cross-origin request to Next.js dev resource, dann ist dies deine Einstellung. Halte Next.js ebenfalls gepatcht. CVE-2026-27977 ließ Origin: null die Websocket-Origin-Schutz in next dev von 16.0.1 bis zum Fix in 16.1.7 umgehen, auch wenn allowedDevOrigins konfiguriert war.

Warum eine stabile Subdomain bedeutet, dass du es einmal konfigurierst

Whitelist-Einträge sind exakt by design, daher hängt der echte Aufwand davon ab, wie oft sich dein öffentlicher Hostname ändert.

Mit einem Wegwerf-Tunnel, der bei jedem Start eine zufällige Subdomain ausgibt, bearbeitest du die Allowlist in jeder Sitzung. Jede Bearbeitung ist auch eine Änderung der Config-Datei, die in ein Commit landen kann, und jedes Teammitglied hat einen anderen Namen. Diese Ermüdung erklärt, warum allowedHosts: true oft in Repositories landet.

Mit einer reservierten, stabilen Subdomain ist der Hostname bekannt, bevor du den Tunnel überhaupt startest. Du fügst my-app.tunnel.example.com einmal zur Allowlist hinzu, commitest ihn, und jedes Teammitglied, jeder CI-Lauf und jeder Webhook-Anbieter zeigt auf denselben Namen. Der Fehler, mit dem du diesen Artikel begonnen hast, hört einfach auf zu passieren. Die gleiche Stabilität hilft allem anderen, das an den Hostnamen gebunden ist: OAuth-Redirect-URIs, Webhook-Endpunkte, CSRF-trusted-origins und gespeicherte Lesezeichen.

Wenn ein Hostname persönlich statt gemeinsam genutzt wird, halte ihn aus dem Repo heraus und lese ihn stattdessen aus einer Umgebungsvariable:

// 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"]

Dasselbe Muster funktioniert in settings.py mit os.environ und in next.config.js mit process.env.

Die Falle von allowedHosts: true

Das Deaktivieren der Prüfung ist eine Zeile Code in jedem der oben genannten Frameworks: Vite’s true, Rails’ config.hosts.clear, Django’s '*', oder true in Angular’s Dev-Server-Option. Es „behebt“ den Fehler sofort, deshalb verbreitet es sich.

Vite’s Dokumentation ist dazu deutlich. Wenn du server.allowedHosts auf true setzt, erlaubt es jeder Website, Anfragen an deinen Dev-Server durch DNS-Rebinding zu senden, sodass sie deinen Quellcode und Inhalt herunterladen. Es empfiehlt sich immer, eine explizite Liste zu verwenden. Du hast die eine Kontrolle deaktiviert, die existierte, um das zu stoppen.

Zwei verwandte Fehlerquellen sind leicht zu machen, während du versuchst, vorsichtig zu sein:

1. Echtzeit-Wildcard vermeiden. Wenn du die gemeinsame Domain eines Tunnel-Anbieters hinzufügst, z. B. .ngrok-free.app, vertrauenswürdige Domäne wird auf eine Domäne erweitert, die du nicht kontrollierst. Die Vite-Anleitung empfiehlt, nur Hosts hinzuzufügen, deren Auflösung du kontrollierst, oder deren Besitzer du vertraust. Bevorzuge deinen eigenen vollständigen Hostnamen oder eine Domain, die dir gehört.
2. Alles „nur zum Demo“-Fall zulassen. Dev-Server überdauern Demos. Halte den expliziten Hostnamen lieber fest.

Eine Copy-Paste-Checkliste

1. Lies den Fehler. Nimmt er den Host und die Einstellung benannt? Dann konfiguriere, nicht den Tunnel.
2. Kopiere den genauen Hostnamen aus der öffentlichen URL, ohne Schema oder Port.
3. Füge ihn an der richtigen Stelle hinzu: server.allowedHosts, config.hosts, ALLOWED_HOSTS, allowedHosts in angular.json, oder allowedDevOrigins.
4. Starte den Dev-Server neu. Konfigurationsdateien werden normalerweise beim Start gelesen.
5. Wenn die Seite lädt, aber Hot-Reload oder Formular-Posts scheitern, prüfe HMR WebSocket-Einstellungen (Vite), CSRF_TRUSTED_ORIGINS (Django) oder Dev-Resource-Warnungen (Next.js).
6. Reserviere eine stabile Subdomain, damit dies das letzte Mal ist, dass du sie bearbeitest.
7. Überprüfe von außerhalb deines Netzwerks, z. B. mit einem Smartphone im Mobilnetz, nicht nur von deinem eigenen Rechner.
8. Committe niemals true, '*' oder eine gemeinsame Provider-Suffix.

FAQ

Warum funktioniert meine App auf localhost, aber nicht durch einen Tunnel?

Auf localhost ist der Host-Header localhost, was von allen Frameworks oben standardmäßig erlaubt wird. Durch einen Tunnel ist es der öffentliche Hostname, der nicht auf einer Standardliste steht.

Ist allowedHosts: true jemals akzeptabel?

Nur auf einer Maschine und einem Netzwerk, das du vollständig kontrollierst, für kurze Zeit, ohne sensible Daten im Projekt. Selbst dann kostet ein expliziter Hostname eine Zeile und vermeidet das Risiko.

Muss ich auch den Port erlauben?

Nein. Django vergleicht Hostnamen ohne den Port, Rails-Strings tolerieren einen optionalen Port, und Next.js-Einträge sollten ohne Port geschrieben werden.

Die Fehlermeldung erwähnt vite.config.js, aber mein Framework hat keines. Was nun?

Suche nach einem Durchreich-Schlüssel: vite.server.allowedHosts in Nuxt, die Admin-Vite-Konfiguration in Strapi (oder Strapi aktualisieren) und allowedHosts in angular.json für Angular.

Beeinträchtigt das die Produktion?

Dies sind Dev-Server-Einstellungen für Vite, Angular und Next.js. Rails und Django verhalten sich anders. Das ALLOWED_HOSTS von Django gilt in der Produktion, und Rails’ config.hosts gilt in jeder Umgebung, in der du es konfigurierst.

Referenzen

• Vite, Server-Optionen und Vorschau-Optionen
• Vite Advisory GHSA-vg6x-rcgg-rjx6
• Rails API, [ActionDispatch::HostAuthorization] und [Pull Request #33145]
• Django, [Settings: ALLOWED_HOSTS and CSRF_TRUSTED_ORIGINS], [1.4.4 Release Notes] und [2016 Security Releases]
• Angular CLI, [ng serve-Optionen], [Pull Request #29466], [Issue #33184] und [Issue #32616]
• Angular Advisory GHSA-xrxm-cp7j-8xf6
• Next.js, [allowedDevOrigins], [Advisory GHSA-3h52-269p-cp9r], [Pull Request #91507] und [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]