Ist eine CORS-Wildcard ein Sicherheitsrisiko? Meist nicht.

Dein Scan kam mit einer Zeile zurück, die sich wie ein Alarm liest: deine API ist für jede Website offen. Oder jemand Technisches hat sich angesehen, was dein Server zurückschickt, und dir gesagt, deine App habe eine CORS-Wildcard, also das Zeichen *, was offenbar alle bedeutet.

Hier ist der Teil, den Ratgeber um Ratgeber falsch darstellt: die Wildcard ist fast nie das, was deine API geöffnet hat. Sie ist eine Anweisung, die dein Server seinen Antworten beilegt, gerichtet an die Browser von Leuten, die auf anderen Websites sitzen, und sie trifft ein, nachdem die Antwort längst hinausgegangen ist. Sie zu verengen hindert die Seite einer fremden Website daran, deine Daten zu lesen. Gegen jemanden, der sie ganz ohne Browser liest, richtet sie nichts aus.

Ist eine CORS-Wildcard ein Sicherheitsrisiko?

Für sich genommen kaum je. Sie wird in dem Moment zu einem, in dem dahinter etwas Privates antwortet.

Die Wildcard ist der Wert * in einem Antwort-Header namens Access-Control-Allow-Origin, und sie bedeutet, dass der Code jeder beliebigen Website diese eine Antwort lesen darf. Das klingt nach einer Aussage darüber, wer an deine Daten herankommt. Es ist eine Aussage darüber, wer lesen darf, was dein Server bereits geschickt hat.

Die Adresse, die ein Scan prüft, ist die, von der deine App ausgeliefert wird. Bei den meisten Buildern gibt diese Adresse deine Seiten, deine Bilder und deinen kompilierten Code heraus, und all das geht von Haus aus an jeden Besucher. Eine Wildcard darauf erteilt die Erlaubnis, Dateien zu lesen, die jeder schon durch das Öffnen deiner Website herunterladen konnte.

Der Befund ist also eine Frage und kein Urteil, und die Frage lautet, was hinter dem Header sitzt. Ist die Antwort deine Startseite, ist nichts passiert. Ist die Antwort eine Liste deiner Kunden, war diese Liste schon für jeden erreichbar, der die Adresse hatte.

Was Access-Control-Allow-Origin tatsächlich tut

Er sagt dem Browser deiner Besucher, ob die Seite auf dem Bildschirm eine Antwort ansehen darf, die dein Server bereits geschickt hat.

Die Reihenfolge ist die ganze Sache, und sie läuft andersherum, als fast jeder sie sich vorstellt. Eine Seite auf irgendeiner fremden Website führt ein Stück Code aus, das deine App nach Daten fragt. Die Anfrage geht hinaus. Dein Server nimmt sie entgegen, führt aus, was er ausführt, und schickt die Antwort vollständig zurück. Erst danach liest der Browser den Header dieser Antwort und entscheidet, ob er den Inhalt an die Seite weitergibt, die danach gefragt hat. Der CORS-Leitfaden von MDN bringt es in einer Zeile: Der Server muss mit Access-Control-Allow-Origin zustimmen, um die Antwort mit dem Skript zu teilen.

Deine Daten haben das Haus so oder so verlassen. Was der Header entscheidet, ist, ob ein bestimmtes Stück Code im Browser einer bestimmten Person sie zu sehen bekommt.

Der Browser ist das Einzige in dieser Geschichte, das den Header liest. Ein Skript auf einem Server, ein Kommandozeilenwerkzeug, ein Scraper, eine Mobil-App: keines davon sieht ihn sich an, denn er wurde für einen Browser geschrieben, und es ist kein Browser beteiligt. Sie schicken dieselbe Anfrage, bekommen dieselbe Antwort und lesen jedes Byte davon.

CORS zu verengen macht einen offenen Endpunkt nicht privat

Weil CORS in Browsern lebt und jemand, der sich an deinen Daten bedient, keinen Grund hat, einen zu benutzen.

Das ist der Teil, der Leute einen Nachmittag kostet. Sie sehen den Wildcard-Befund, verengen den Header auf ihre eigene Domain, deployen neu, scannen neu, und die Adresse, die Kundenzeilen herausgab, gibt weiterhin Kundenzeilen heraus. Das tat sie immer. Der einzige Aufrufer, der je aufgehalten wurde, war die Webseite eines anderen.

Lies die unterste Zeile zweimal, denn dort kippt der allgemeine Rat. Eine reine Wildcard kann nicht dazu benutzt werden, Daten deines angemeldeten Besuchers zu lesen. Browser verweigern diese Kombination rundheraus, und der CORS-Leitfaden von MDN sagt es direkt: Führt eine Anfrage ein Cookie mit und kommt die Antwort mit Access-Control-Allow-Origin: * zurück, blockiert der Browser den Zugriff auf die Antwort und meldet einen CORS-Fehler in der Konsole. Ausgerechnet die Wildcard ist es also, die genau diesen Angriff unmöglich macht.

Die Spalte, die die Daten eines angemeldeten Nutzers tatsächlich herausgibt, ist die dritte, und dafür muss der Server die Adresse des Aufrufers in seine eigene Antwort schreiben.

Die CORS-Einstellung, die wirklich gefährlich ist

Ein Server, der den Origin-Header aus der Anfrage liest, denselben Wert in seine eigene Antwort schreibt und Access-Control-Allow-Credentials: true dazulegt.

Niemand nimmt sich das vor. Es entsteht am Ende eines Nachmittags, an dem versucht wurde, eine Wildcard mit angemeldeten Anfragen zum Laufen zu bringen, und sich herausstellte, dass sie das nie tun wird. Zurückzuspiegeln, welche Origin gerade fragt, sieht nach dem Ausweg aus: Jede Seite, die erlaubt sein soll, ist erlaubt, die Konsolenfehler hören auf, das Feature geht live. Was der Server damit sagt, ist, dass der Aufrufer entscheidet, und dazu gehört eine Seite, die noch niemand geschrieben hat.

Und das erlaubt es. Deine Kundin ist in deiner App angemeldet, mit einem Sitzungscookie in ihrem Browser. In einem anderen Tab öffnet sie eine Seite, die nichts mit dir zu tun hat. Der Code dieser Seite fragt deine API nach ihrem Konto. Ihr Browser legt das Cookie bei, denn Cookies beizulegen ist das, was Browser tun. Dein Server liest eine Origin, von der er nie gehört hat, stempelt sie als Erlaubnis in die Antwort und ergänzt, dass Credentials in Ordnung sind. Der Browser prüft, findet eine Übereinstimmung und reicht die Daten deiner Kundin an eine Seite weiter, von der sie nicht wusste, dass sie mitliest.

In unserem Sweep vom August 2026 tauchte das bei 61 der 30.926 Apps auf, bei denen die Prüfung eine Antwort bekam. Von den drei CORS-Befunden ist es der einzige, der an Daten hinter einem Login heranreicht.

Wie oft eine Wildcard auftaucht, und wer darüber entscheidet

Meistens entscheidet dein Builder. Im selben Sweep schickten 5.727 dieser 30.926 Apps eine Wildcard, und der beste einzelne Vorhersagewert dafür, ob deine das tut, ist die Plattform, die sie veröffentlicht hat.

Die CORS-Prüfung meldete bei 5.418 der 5.419 Base44-Apps, bei denen sie eine Antwort bekam, mindestens einen Befund, und bei 8 der 18.518 Lovable-Apps. Replit lag mit 1.129 von 3.037 dazwischen. Eine so weite Spanne ist das, wonach eine Hosting-Voreinstellung von außen aussieht: nahezu vollständig auf der einen Plattform, so gut wie abwesend auf der anderen, über Tausende von Apps hinweg, deren Betreiber nie irgendetwas abgestimmt haben.

Drei getrennte Befunde bilden die CORS-Prüfung über alle 30.926 Apps: eine Wildcard bei 5.727 von ihnen, eine Adresse, die Daten ohne Login herausgibt, bei 3.852, und die zurückgespiegelte Origin bei 61. Zusammen ergibt das mehr als die Prüfung selbst, denn viele Apps haben zwei der drei. Jede Zahl hier stammt aus unserem Scan von 30.998 lebenden vibe-codeten Apps, der jede einzelne mitsamt der Basis veröffentlicht, über die sie gemessen wurde.

Was davon in deiner Hand liegt, teilt sich genauso auf. Die Wildcard schickt derjenige, der deine App ausliefert, und bei einer vibe-codeten App ist das meistens der Builder. Was zurückkommt, wenn ein Fremder eine deiner Adressen nach Daten fragt, wurde in deiner App entschieden, von dir oder von dem Builder, der in deinem Auftrag Code schreibt.

So prüfst du deine eigene App

Zwei Dinge sind anzusehen, und das zweite entscheidet, ob irgendetwas davon eine Rolle spielt.

Schickt deine App eine Wildcard? Öffne deine live geschaltete App, drücke F12, um die Entwicklerwerkzeuge des Browsers zu öffnen, klicke auf Network und lade die Seite neu. Klicke auf die erste Anfrage in der Liste und lies das Feld Response Headers. Eine Zeile mit access-control-allow-origin: * ist der Befund. Gar keine solche Zeile heißt, dass dein Server über Origins hinweg mit niemandem etwas teilt.

Was antwortet dahinter? Bleib im Network-Tab und lade deine App neu, während du angemeldet bist, und achte auf Anfragen, die als JSON zurückkommen. Das sind die Adressen, von denen deine App Daten holt. Kopiere jede URL, öffne ein privates Browserfenster, sodass du abgemeldet bist, und füge sie eine nach der anderen ein. Alles, was mit echten Zeilen zurückkommt statt mit einem Fehler oder einer leeren Liste, ist für jeden im Internet lesbar, der diese URL hat. Das gilt heute, was auch immer dein CORS-Header sagt, und es gilt weiter, nachdem du ihn verengt hast.

Unser kostenloser Scan übernimmt die zweite Prüfung für dich: Er liest den Code deiner App nach den Adressen aus, die sie aufruft, fragt jede davon ohne Login ab und meldet die, die mit Daten geantwortet haben. Er dauert etwa 20 Sekunden und braucht kein Konto: scanne deine App.

Wenn deine App direkt aus dem Browser mit Supabase spricht, gibt es eine dritte Stelle zum Nachsehen, denn die Regeln an jeder Tabelle entscheiden, wer welche Zeilen lesen darf, und sie einzuschalten ist nicht dasselbe wie geschützt zu sein.

Was jetzt zu tun ist

Die Gewohnheit, die sich lohnt, ist der abgemeldete Durchgang über deine eigenen Datenadressen, denn jedes neue Feature bringt eine weitere hinzu, und auf dem Bildschirm sieht nichts anders aus, wenn eine davon zu antworten beginnt. Reeve Care lässt diesen Scan nach Zeitplan erneut gegen deine live geschaltete App laufen und schickt dir eine E-Mail, wenn ein Ergebnis schlechter wird: was es überwacht und was es kostet.

Wenn du lieber alles in einem Rutsch durcharbeitest, deckt die 10-Minuten-Sicherheitscheckliste das hier neben dem Rest ab, was eine frisch gestartete App gern offen lässt, und welche Schlüssel in deinem Frontend sicher sind ist die andere Hälfte der Frage, mit der Leute normalerweise ankommen.