[{"data":1,"prerenderedAt":380},["ShallowReactive",2],{"blog-de-cors-wildcard-security-risk":3},{"id":4,"title":5,"body":6,"category":339,"cover":340,"coverAlt":341,"description":342,"draft":343,"extension":344,"faq":345,"image":361,"keywords":362,"meta":369,"navigation":370,"ogTitle":30,"path":371,"published":372,"seo":373,"stem":374,"tldr":375,"updated":372,"__hash__":379},"blog_de\u002Fblog\u002Fcors-wildcard-security-risk.md","Ist eine CORS-Wildcard ein Sicherheitsrisiko? Meist nicht.",{"type":7,"value":8,"toc":327},"minimark",[9,18,26,31,34,44,47,50,54,57,63,66,72,75,79,82,85,168,175,178,182,193,196,202,207,210,214,217,220,229,232,236,239,257,263,271,278,282,307,314],[10,11,12,13,17],"p",{},"Dein Scan kam mit einer Zeile zurück, die sich wie ein Alarm liest: deine API\nist für jede Website offen. Oder jemand Technisches hat sich angesehen, was dein\nServer zurückschickt, und dir gesagt, deine App habe eine CORS-Wildcard, also\ndas Zeichen ",[14,15,16],"code",{},"*",", was offenbar alle bedeutet.",[10,19,20,21,25],{},"Hier ist der Teil, den Ratgeber um Ratgeber falsch darstellt: ",[22,23,24],"strong",{},"die Wildcard ist\nfast nie das, was deine API geöffnet hat."," Sie ist eine Anweisung, die dein\nServer seinen Antworten beilegt, gerichtet an die Browser von Leuten, die auf\nanderen Websites sitzen, und sie trifft ein, nachdem die Antwort längst\nhinausgegangen ist. Sie zu verengen hindert die Seite einer fremden Website\ndaran, deine Daten zu lesen. Gegen jemanden, der sie ganz ohne Browser liest,\nrichtet sie nichts aus.",[27,28,30],"h2",{"id":29},"ist-eine-cors-wildcard-ein-sicherheitsrisiko","Ist eine CORS-Wildcard ein Sicherheitsrisiko?",[10,32,33],{},"Für sich genommen kaum je. Sie wird in dem Moment zu einem, in dem dahinter\netwas Privates antwortet.",[10,35,36,37,39,40,43],{},"Die Wildcard ist der Wert ",[14,38,16],{}," in einem Antwort-Header namens\n",[14,41,42],{},"Access-Control-Allow-Origin",", und sie bedeutet, dass der Code jeder beliebigen\nWebsite diese eine Antwort lesen darf. Das klingt nach einer Aussage darüber,\nwer an deine Daten herankommt. Es ist eine Aussage darüber, wer lesen darf, was\ndein Server bereits geschickt hat.",[10,45,46],{},"Die Adresse, die ein Scan prüft, ist die, von der deine App ausgeliefert wird.\nBei den meisten Buildern gibt diese Adresse deine Seiten, deine Bilder und\ndeinen kompilierten Code heraus, und all das geht von Haus aus an jeden\nBesucher. Eine Wildcard darauf erteilt die Erlaubnis, Dateien zu lesen, die\njeder schon durch das Öffnen deiner Website herunterladen konnte.",[10,48,49],{},"Der Befund ist also eine Frage und kein Urteil, und die Frage lautet, was hinter\ndem Header sitzt. Ist die Antwort deine Startseite, ist nichts passiert. Ist die\nAntwort eine Liste deiner Kunden, war diese Liste schon für jeden erreichbar,\nder die Adresse hatte.",[27,51,53],{"id":52},"was-access-control-allow-origin-tatsächlich-tut","Was Access-Control-Allow-Origin tatsächlich tut",[10,55,56],{},"Er sagt dem Browser deiner Besucher, ob die Seite auf dem Bildschirm eine\nAntwort ansehen darf, die dein Server bereits geschickt hat.",[10,58,59,60,62],{},"Die Reihenfolge ist die ganze Sache, und sie läuft andersherum, als fast jeder\nsie sich vorstellt. Eine Seite auf irgendeiner fremden Website führt ein Stück\nCode aus, das deine App nach Daten fragt. Die Anfrage geht hinaus. Dein Server\nnimmt sie entgegen, führt aus, was er ausführt, und schickt die Antwort\nvollständig zurück. Erst danach liest der Browser den Header dieser Antwort und\nentscheidet, ob er den Inhalt an die Seite weitergibt, die danach gefragt hat.\nDer CORS-Leitfaden von MDN bringt es in einer Zeile: Der Server muss mit\n",[14,61,42],{}," zustimmen, um die Antwort mit dem Skript zu\nteilen.",[10,64,65],{},"Deine Daten haben das Haus so oder so verlassen. Was der Header entscheidet,\nist, ob ein bestimmtes Stück Code im Browser einer bestimmten Person sie zu\nsehen bekommt.",[67,68],"diagram",{"alt":69,"caption":70,"src":71},"Ein Server beantwortet zwei Aufrufer mit einer identischen Antwort. In der oberen Spur erreicht die Antwort einen Browser, der sie an einer Barriere festhält, sodass die Seite dahinter nichts bekommt. In der unteren Spur gibt es überhaupt keine Barriere, und dieselbe Antwort kommt unversehrt in einem Terminalfenster an.","Beide Aufrufer bekommen eine Antwort, denn der Server schickt sie ab, bevor irgendetwas geprüft wird. Die Barriere in der oberen Spur ist der Browser, und in der unteren Spur kommt gar kein Browser vor.","\u002Fblog\u002Fcors-wildcard-security-risk\u002Fwho-reads-the-header-1600x650.png",[10,73,74],{},"Der Browser ist das Einzige in dieser Geschichte, das den Header liest. Ein\nSkript auf einem Server, ein Kommandozeilenwerkzeug, ein Scraper, eine\nMobil-App: keines davon sieht ihn sich an, denn er wurde für einen Browser\ngeschrieben, und es ist kein Browser beteiligt. Sie schicken dieselbe Anfrage,\nbekommen dieselbe Antwort und lesen jedes Byte davon.",[27,76,78],{"id":77},"cors-zu-verengen-macht-einen-offenen-endpunkt-nicht-privat","CORS zu verengen macht einen offenen Endpunkt nicht privat",[10,80,81],{},"Weil CORS in Browsern lebt und jemand, der sich an deinen Daten bedient, keinen\nGrund hat, einen zu benutzen.",[10,83,84],{},"Das ist der Teil, der Leute einen Nachmittag kostet. Sie sehen den\nWildcard-Befund, verengen den Header auf ihre eigene Domain, deployen neu,\nscannen neu, und die Adresse, die Kundenzeilen herausgab, gibt weiterhin\nKundenzeilen heraus. Das tat sie immer. Der einzige Aufrufer, der je\naufgehalten wurde, war die Webseite eines anderen.",[86,87,88,109],"table",{},[89,90,91],"thead",{},[92,93,94,98,103,106],"tr",{},[95,96,97],"th",{},"Was jemand versucht",[95,99,100,101],{},"Wildcard ",[14,102,16],{},[95,104,105],{},"Nur deine Domain",[95,107,108],{},"Jede Origin zurückgespiegelt, Credentials erlaubt",[110,111,112,125,136,148],"tbody",{},[92,113,114,118,121,123],{},[115,116,117],"td",{},"Die Adresse in einem Browser-Tab öffnen",[115,119,120],{},"Funktioniert",[115,122,120],{},[115,124,120],{},[92,126,127,130,132,134],{},[115,128,129],{},"Sie mit einem Skript oder im Terminal lesen",[115,131,120],{},[115,133,120],{},[115,135,120],{},[92,137,138,141,143,146],{},[115,139,140],{},"Eine Seite auf einer fremden Website liest sie",[115,142,120],{},[115,144,145],{},"Blockiert",[115,147,120],{},[92,149,150,153,159,163],{},[115,151,152],{},"Eine fremde Website liest sie als dein angemeldeter Nutzer",[115,154,155],{},[156,157,145],"key-verdict",{"type":158},"safe",[115,160,161],{},[156,162,145],{"type":158},[115,164,165],{},[156,166,120],{"type":167},"danger",[10,169,170,171,174],{},"Lies die unterste Zeile zweimal, denn dort kippt der allgemeine Rat. Eine reine\nWildcard kann nicht dazu benutzt werden, Daten deines angemeldeten Besuchers zu\nlesen. Browser verweigern diese Kombination rundheraus, und der CORS-Leitfaden\nvon MDN sagt es direkt: Führt eine Anfrage ein Cookie mit und kommt die Antwort\nmit ",[14,172,173],{},"Access-Control-Allow-Origin: *"," zurück, blockiert der Browser den Zugriff\nauf die Antwort und meldet einen CORS-Fehler in der Konsole. Ausgerechnet die\nWildcard ist es also, die genau diesen Angriff unmöglich macht.",[10,176,177],{},"Die Spalte, die die Daten eines angemeldeten Nutzers tatsächlich herausgibt, ist\ndie dritte, und dafür muss der Server die Adresse des Aufrufers in seine eigene\nAntwort schreiben.",[27,179,181],{"id":180},"die-cors-einstellung-die-wirklich-gefährlich-ist","Die CORS-Einstellung, die wirklich gefährlich ist",[10,183,184,185,188,189,192],{},"Ein Server, der den ",[14,186,187],{},"Origin","-Header aus der Anfrage liest, denselben Wert in\nseine eigene Antwort schreibt und ",[14,190,191],{},"Access-Control-Allow-Credentials: true","\ndazulegt.",[10,194,195],{},"Niemand nimmt sich das vor. Es entsteht am Ende eines Nachmittags, an dem\nversucht wurde, eine Wildcard mit angemeldeten Anfragen zum Laufen zu bringen,\nund sich herausstellte, dass sie das nie tun wird. Zurückzuspiegeln, welche\nOrigin gerade fragt, sieht nach dem Ausweg aus: Jede Seite, die erlaubt sein\nsoll, ist erlaubt, die Konsolenfehler hören auf, das Feature geht live. Was der\nServer damit sagt, ist, dass der Aufrufer entscheidet, und dazu gehört eine\nSeite, die noch niemand geschrieben hat.",[10,197,198,199,201],{},"Und das erlaubt es. Deine Kundin ist in deiner App angemeldet, mit einem\nSitzungscookie in ihrem Browser. In einem anderen Tab öffnet sie eine Seite, die\nnichts mit dir zu tun hat. Der Code dieser Seite fragt deine API nach ihrem\nKonto. Ihr Browser legt das Cookie bei, denn Cookies beizulegen ist das, was\nBrowser tun. Dein Server liest eine ",[14,200,187],{},", von der er nie gehört hat, stempelt\nsie als Erlaubnis in die Antwort und ergänzt, dass Credentials in Ordnung sind.\nDer Browser prüft, findet eine Übereinstimmung und reicht die Daten deiner Kundin\nan eine Seite weiter, von der sie nicht wusste, dass sie mitliest.",[67,203],{"alt":204,"caption":205,"src":206},"Eine Anfrage verlässt eine unbekannte Website und führt ein rotes Namensschild und ein Cookie mit. Der Server kopiert dasselbe rote Schild in das Erlaubnisfeld seiner Antwort. Der Browser vergleicht die beiden Schilder, findet sie gleich und lässt die Daten zur Seite durch.","Der Aufrufer liefert den Namen, und der Server schreibt diesen Namen auf den Passierschein. Wer fragt, steht auf der Liste, und genau darin unterscheidet sich dieser Fall von einer Wildcard.","\u002Fblog\u002Fcors-wildcard-security-risk\u002Fthe-echoed-origin-1600x680.png",[10,208,209],{},"In unserem Sweep vom August 2026 tauchte das bei 61 der 30.926 Apps auf, bei\ndenen die Prüfung eine Antwort bekam. Von den drei CORS-Befunden ist es der\neinzige, der an Daten hinter einem Login heranreicht.",[27,211,213],{"id":212},"wie-oft-eine-wildcard-auftaucht-und-wer-darüber-entscheidet","Wie oft eine Wildcard auftaucht, und wer darüber entscheidet",[10,215,216],{},"Meistens entscheidet dein Builder. Im selben Sweep schickten 5.727 dieser 30.926\nApps eine Wildcard, und der beste einzelne Vorhersagewert dafür, ob deine das\ntut, ist die Plattform, die sie veröffentlicht hat.",[10,218,219],{},"Die CORS-Prüfung meldete bei 5.418 der 5.419 Base44-Apps, bei denen sie eine\nAntwort bekam, mindestens einen Befund, und bei 8 der 18.518 Lovable-Apps.\nReplit lag mit 1.129 von 3.037 dazwischen. Eine so weite Spanne ist das, wonach\neine Hosting-Voreinstellung von außen aussieht: nahezu vollständig auf der einen\nPlattform, so gut wie abwesend auf der anderen, über Tausende von Apps hinweg,\nderen Betreiber nie irgendetwas abgestimmt haben.",[10,221,222,223,228],{},"Drei getrennte Befunde bilden die CORS-Prüfung über alle 30.926 Apps: eine\nWildcard bei 5.727 von ihnen, eine Adresse, die Daten ohne Login herausgibt, bei\n3.852, und die zurückgespiegelte Origin bei 61. Zusammen ergibt das mehr als die\nPrüfung selbst, denn viele Apps haben zwei der drei. Jede Zahl hier stammt aus\n",[224,225,227],"a",{"href":226},"\u002Fresearch\u002Fvibe-coded-app-security-2026","unserem Scan von 30.998 lebenden vibe-codeten Apps",",\nder jede einzelne mitsamt der Basis veröffentlicht, über die sie gemessen wurde.",[10,230,231],{},"Was davon in deiner Hand liegt, teilt sich genauso auf. Die Wildcard schickt\nderjenige, der deine App ausliefert, und bei einer vibe-codeten App ist das\nmeistens der Builder. Was zurückkommt, wenn ein Fremder eine deiner Adressen\nnach Daten fragt, wurde in deiner App entschieden, von dir oder von dem Builder,\nder in deinem Auftrag Code schreibt.",[27,233,235],{"id":234},"so-prüfst-du-deine-eigene-app","So prüfst du deine eigene App",[10,237,238],{},"Zwei Dinge sind anzusehen, und das zweite entscheidet, ob irgendetwas davon eine\nRolle spielt.",[10,240,241,244,245,248,249,252,253,256],{},[22,242,243],{},"Schickt deine App eine Wildcard?"," Öffne deine live geschaltete App, drücke\nF12, um die Entwicklerwerkzeuge des Browsers zu öffnen, klicke auf ",[22,246,247],{},"Network","\nund lade die Seite neu. Klicke auf die erste Anfrage in der Liste und lies das\nFeld ",[22,250,251],{},"Response Headers",". Eine Zeile mit ",[14,254,255],{},"access-control-allow-origin: *"," ist\nder Befund. Gar keine solche Zeile heißt, dass dein Server über Origins hinweg\nmit niemandem etwas teilt.",[10,258,259,262],{},[22,260,261],{},"Was antwortet dahinter?"," Bleib im Network-Tab und lade deine App neu, während\ndu angemeldet bist, und achte auf Anfragen, die als JSON zurückkommen. Das sind\ndie Adressen, von denen deine App Daten holt. Kopiere jede URL, öffne ein\nprivates Browserfenster, sodass du abgemeldet bist, und füge sie eine nach der\nanderen ein. Alles, was mit echten Zeilen zurückkommt statt mit einem Fehler\noder einer leeren Liste, ist für jeden im Internet lesbar, der diese URL hat.\nDas gilt heute, was auch immer dein CORS-Header sagt, und es gilt weiter,\nnachdem du ihn verengt hast.",[10,264,265,266,270],{},"Unser kostenloser Scan übernimmt die zweite Prüfung für dich: Er liest den Code\ndeiner App nach den Adressen aus, die sie aufruft, fragt jede davon ohne Login\nab und meldet die, die mit Daten geantwortet haben. Er dauert etwa 20 Sekunden\nund braucht kein Konto: ",[224,267,269],{"href":268},"\u002F#scan","scanne deine App",".",[10,272,273,274,270],{},"Wenn deine App direkt aus dem Browser mit Supabase spricht, gibt es eine dritte\nStelle zum Nachsehen, denn die Regeln an jeder Tabelle entscheiden, wer welche\nZeilen lesen darf, und\n",[224,275,277],{"href":276},"\u002Fblog\u002Fsupabase-rls-on-but-table-still-public","sie einzuschalten ist nicht dasselbe wie geschützt zu sein",[27,279,281],{"id":280},"was-jetzt-zu-tun-ist","Was jetzt zu tun ist",[283,284,285],"key-takeaways",{},[286,287,288,292,295,298,304],"ul",{},[289,290,291],"li",{},"Nimm einen Wildcard-Befund als Frage danach, was hinter dem Header steht. Auf der Adresse, von der deine App ausgeliefert wird, erlaubt er meist das Lesen von Dateien, die ohnehin jeder Besucher herunterlädt.",[289,293,294],{},"Melde dich ab und öffne jede Datenadresse, die deine App aufruft. Alles, was einem abgemeldeten Browser echte Zeilen zurückgibt, ist für alle öffentlich, was der Header auch sagt.",[289,296,297],{},"Behebe eine offene Adresse an der Adresse: verlange einen Login und antworte einem Fremden mit einem 401. Den CORS-Header zu verengen lässt sie für alles erreichbar außer für die Webseiten anderer Leute.",[289,299,300,301,303],{},"Wenn dein Server zurückspiegelt, welche Origin gefragt hat, und ",[14,302,191],{}," schickt, ersetze das heute durch eine Liste deiner eigenen Domains. Das ist der eine Fall hier, in dem eine fremde Seite Daten als dein angemeldeter Nutzer liest.",[289,305,306],{},"Kommt der Header vom Hosting deines Builders und du kannst ihn nicht ändern, verwende die Zeit stattdessen auf die Endpunkte. Dort liegen deine Daten.",[10,308,309,310,270],{},"Die Gewohnheit, die sich lohnt, ist der abgemeldete Durchgang über deine eigenen\nDatenadressen, denn jedes neue Feature bringt eine weitere hinzu, und auf dem\nBildschirm sieht nichts anders aus, wenn eine davon zu antworten beginnt. Reeve\nCare lässt diesen Scan nach Zeitplan erneut gegen deine live geschaltete App\nlaufen und schickt dir eine E-Mail, wenn ein Ergebnis schlechter wird:\n",[224,311,313],{"href":312},"\u002F#pricing","was es überwacht und was es kostet",[10,315,316,317,321,322,326],{},"Wenn du lieber alles in einem Rutsch durcharbeitest, deckt die\n",[224,318,320],{"href":319},"\u002Fchecklist","10-Minuten-Sicherheitscheckliste"," das hier neben dem Rest ab, was\neine frisch gestartete App gern offen lässt, und\n",[224,323,325],{"href":324},"\u002Fblog\u002Fwhich-api-keys-are-safe-in-your-frontend","welche Schlüssel in deinem Frontend sicher sind","\nist die andere Hälfte der Frage, mit der Leute normalerweise ankommen.",{"title":328,"searchDepth":329,"depth":329,"links":330},"",3,[331,333,334,335,336,337,338],{"id":29,"depth":332,"text":30},2,{"id":52,"depth":332,"text":53},{"id":77,"depth":332,"text":78},{"id":180,"depth":332,"text":181},{"id":212,"depth":332,"text":213},{"id":234,"depth":332,"text":235},{"id":280,"depth":332,"text":281},"Sicherheitsgrundlagen","\u002Fblog\u002Fcors-wildcard-security-risk\u002Fcover-1200x630.png","Sechs verschiedene Aufrufer erreichen einen Server, und dieselbe Antwort läuft zu jedem von ihnen zurück.","Ist eine CORS-Wildcard ein Sicherheitsrisiko? Meist ist sie die Voreinstellung deines Builders und gibt nichts preis, was dein Server nicht ohnehin herausgab.",false,"md",[346,349,352,355,358],{"q":347,"a":348},"Mein Scan sagt, meine API sei für jede Website offen. Muss ich das beheben?","Sieh zuerst nach, was dahinter antwortet. Eine Wildcard auf der Adresse, von der deine App ausgeliefert wird, erlaubt üblicherweise das Lesen deiner Seiten, Bilder und deines kompilierten Codes, und all das lädt jeder Besucher ohnehin herunter. Zu beheben ist es dann, wenn eine Adresse hinter diesem Header echte Daten an jemanden herausgibt, der nicht angemeldet ist, und behoben wird es an dieser Adresse, indem du dort einen Login verlangst.",{"q":350,"a":351},"Wird meine API privat, wenn ich CORS auf meine eigene Domain beschränke?","Nein. CORS ist eine Regel, die Browser auf sich selbst anwenden, sie betrifft also immer nur Code, der auf der Webseite eines anderen läuft. Ein Skript, ein Terminalbefehl oder ein Scraper schickt dieselbe Anfrage und liest dieselbe Antwort, denn keiner von ihnen sieht sich den Header an. Wenn eine Adresse deine Daten ohne Login herausgibt, tut sie das für alle, was auch immer der Header sagt.",{"q":353,"a":354},"Kann eine fremde Website wegen einer Wildcard die Daten meiner angemeldeten Nutzer lesen?","Mit einer reinen Wildcard nicht. Browser verweigern diese Kombination: Der CORS-Leitfaden von MDN hält fest, dass der Browser den Zugriff auf die Antwort blockiert und einen CORS-Fehler protokolliert, wenn eine Anfrage ein Cookie mitführt und die Antwort mit Access-Control-Allow-Origin auf der Wildcard zurückkommt. Was tatsächlich funktioniert, ist ein Server, der die anfragende Origin zurückspiegelt und dazu Access-Control-Allow-Credentials auf true setzt.",{"q":356,"a":357},"Wie ändere ich den CORS-Header bei einer Lovable- oder Base44-App?","Oft gar nicht, denn den Header schickt das Hosting, auf das dein Builder veröffentlicht, und er gilt für jede App auf dieser Plattform. Das ist gut zu wissen, bevor du eine Woche darauf verwendest. Was du immer ändern kannst, ist das, was deine eigenen Endpunkte an eine Anfrage ohne Login zurückgeben, und dorthin gehört die Behebung ohnehin.",{"q":359,"a":360},"Mein Scan hat auch offene API-Endpunkte gemeldet. Ist das derselbe Befund?","Es ist ein anderer, und der schwerwiegendere von beiden. Eine Wildcard beschreibt, wer eine Antwort lesen darf. Ein offener Endpunkt bedeutet, dass die Antwort deine Daten enthielt und ankam, ohne dass sich jemand angemeldet hat. Das Zweite gilt für einen Browser, ein Skript und einen Fremden mit der URL gleichermaßen, und deinen CORS-Header zu verengen ändert nichts daran.","\u002Fblog\u002Fcors-wildcard-security-risk\u002Fcard-800x500.png",[363,364,365,366,367,368],"cors wildcard sicherheitsrisiko","access-control-allow-origin wildcard","ist eine cors wildcard gefährlich","cors fehlkonfiguration","api für jede website offen","access-control-allow-credentials true",{},true,"\u002Fblog\u002Fcors-wildcard-security-risk","2026-08-26",{"title":5,"description":342},"blog\u002Fcors-wildcard-security-risk",[376,377,378],"Eine CORS-Wildcard ist nur dann ein Sicherheitsrisiko, wenn dahinter etwas Privates antwortet. Für sich genommen erlaubt sie das Lesen von Dingen, die jeder ohnehin herunterladen konnte.","Der Header ist eine Anweisung an den Browser deiner Besucher, und er trifft ein, nachdem die Antwort schon abgeschickt ist. Außerhalb eines Browsers liest ihn niemand, ein offener Endpunkt bleibt also genauso offen.","Einen Abend wert ist der Fall, in dem ein Server zurückspiegelt, welche Website gerade fragt, und dazu Credentials erlaubt. Dann liest eine fremde Seite Daten als dein angemeldeter Nutzer.","m2f4DS830CgB8OL56QDwEph9ljwiI1qle1qTgC4Gfdg",1787826048205]