[{"data":1,"prerenderedAt":379},["ShallowReactive",2],{"blog-it-cors-wildcard-security-risk":3},{"id":4,"title":5,"body":6,"category":338,"cover":339,"coverAlt":340,"description":341,"draft":342,"extension":343,"faq":344,"image":360,"keywords":361,"meta":368,"navigation":369,"ogTitle":30,"path":370,"published":371,"seo":372,"stem":373,"tldr":374,"updated":371,"__hash__":378},"blog_it\u002Fblog\u002Fcors-wildcard-security-risk.md","Un wildcard CORS è un rischio di sicurezza? Quasi mai.",{"type":7,"value":8,"toc":326},"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,270,277,281,306,313],[10,11,12,13,17],"p",{},"La tua scansione è tornata con una riga che si legge come un allarme: la tua API\nè aperta a qualsiasi sito. Oppure qualcuno di tecnico ha guardato che cosa\nrimanda il tuo server e ti ha detto che la tua app ha un wildcard CORS, cioè il\ncarattere ",[14,15,16],"code",{},"*",", che a quanto pare significa tutti.",[10,19,20,21,25],{},"Ecco la parte che guida dopo guida racconta male: ",[22,23,24],"strong",{},"il wildcard non è quasi mai\nciò che ha aperto la tua API."," È un'istruzione che il tuo server allega alle\nproprie risposte, indirizzata ai browser di persone che stanno su altri siti, e\narriva dopo che la risposta è già uscita. Restringerlo impedisce alla pagina di\nun altro sito di leggere i tuoi dati. Non fa nulla contro chi li legge senza\nalcun browser.",[27,28,30],"h2",{"id":29},"un-wildcard-cors-è-un-rischio-di-sicurezza","Un wildcard CORS è un rischio di sicurezza?",[10,32,33],{},"Da solo, quasi mai. Lo diventa nel momento in cui dietro risponde qualcosa di\nprivato.",[10,35,36,37,39,40,43],{},"Il wildcard è il valore ",[14,38,16],{}," in un header di risposta chiamato\n",[14,41,42],{},"Access-Control-Allow-Origin",", e significa che il codice di qualsiasi sito può\nleggere quella particolare risposta. Sembra un'affermazione su chi può arrivare\nai tuoi dati. È un'affermazione su chi può leggere ciò che il tuo server ha già\nmandato.",[10,45,46],{},"L'indirizzo che una scansione controlla è quello da cui viene servita la tua\napp. Sulla maggior parte dei builder quell'indirizzo distribuisce le tue pagine,\nle tue immagini e il tuo codice compilato, e tutto questo va a ogni visitatore\nper come è progettato. Un wildcard lì sopra concede il permesso di leggere file\nche chiunque poteva già scaricare aprendo il tuo sito.",[10,48,49],{},"Il rilievo è quindi una domanda e non un verdetto, e la domanda è che cosa sta\ndietro l'header. Se la risposta è la tua home page, non è successo niente. Se la\nrisposta è un elenco dei tuoi clienti, quell'elenco era già raggiungibile da\nchiunque avesse l'indirizzo.",[27,51,53],{"id":52},"che-cosa-fa-davvero-access-control-allow-origin","Che cosa fa davvero Access-Control-Allow-Origin",[10,55,56],{},"Dice al browser del tuo visitatore se la pagina che ha sullo schermo può\nguardare una risposta che il tuo server ha già mandato.",[10,58,59,60,62],{},"L'ordine è tutto, e va al contrario di come se lo immagina quasi chiunque. Una\npagina su un altro sito esegue un pezzo di codice che chiede dati alla tua app.\nLa richiesta parte. Il tuo server la riceve, esegue quello che deve eseguire e\nrimanda indietro la risposta per intero. Solo a quel punto il browser legge\nl'header di quella risposta e decide se consegnare il contenuto alla pagina che\nlo ha chiesto. La guida CORS di MDN lo mette in una riga: il server deve dare il\nproprio assenso con ",[14,61,42],{}," per condividere la risposta\ncon lo script.",[10,64,65],{},"I tuoi dati hanno lasciato l'edificio in entrambi i casi. Quello che l'header\ndecide è se un preciso pezzo di codice, in esecuzione dentro il browser di una\nprecisa persona, arriva a vederli.",[67,68],"diagram",{"alt":69,"caption":70,"src":71},"Un server risponde a due chiamanti con una risposta identica. Nella corsia in alto la risposta raggiunge un browser, che la trattiene a una barriera così che la pagina dietro non riceve nulla. Nella corsia in basso non c'è alcuna barriera e la stessa risposta arriva intatta in una finestra di terminale.","Entrambi i chiamanti ottengono una risposta, perché il server la manda prima che venga controllato qualsiasi cosa. La barriera nella corsia in alto è il browser, e nella corsia in basso di browser non ce n'è nessuno.","\u002Fblog\u002Fcors-wildcard-security-risk\u002Fwho-reads-the-header-1600x650.png",[10,73,74],{},"Il browser è l'unica cosa in questa storia che legga l'header. Uno script su un\nserver, uno strumento da riga di comando, uno scraper, un'app per telefono:\nnessuno di loro lo consulta, perché è stato scritto per un browser e di browser\nnon ce n'è. Mandano la stessa richiesta, ottengono la stessa risposta e ne\nleggono ogni byte.",[27,76,78],{"id":77},"restringere-cors-non-rende-privato-un-endpoint-aperto","Restringere CORS non rende privato un endpoint aperto",[10,80,81],{},"Perché CORS vive dentro i browser, e chi si sta servendo dei tuoi dati non ha\nmotivo di usarne uno.",[10,83,84],{},"È la parte che costa un pomeriggio. Si vede il rilievo del wildcard, si\nrestringe l'header al proprio dominio, si ridistribuisce, si riscansiona, e\nl'indirizzo che distribuiva righe di clienti continua a distribuire righe di\nclienti. Lo ha sempre fatto. L'unico chiamante che si sia mai fermato era la\npagina web di qualcun altro.",[86,87,88,109],"table",{},[89,90,91],"thead",{},[92,93,94,98,103,106],"tr",{},[95,96,97],"th",{},"Che cosa prova a fare qualcuno",[95,99,100,101],{},"Wildcard ",[14,102,16],{},[95,104,105],{},"Solo il tuo dominio",[95,107,108],{},"Qualsiasi origine rimandata come eco, credenziali ammesse",[110,111,112,125,136,148],"tbody",{},[92,113,114,118,121,123],{},[115,116,117],"td",{},"Aprire l'indirizzo in una scheda del browser",[115,119,120],{},"Funziona",[115,122,120],{},[115,124,120],{},[92,126,127,130,132,134],{},[115,128,129],{},"Leggerlo da uno script o da un terminale",[115,131,120],{},[115,133,120],{},[115,135,120],{},[92,137,138,141,143,146],{},[115,139,140],{},"La pagina di un altro sito che lo legge",[115,142,120],{},[115,144,145],{},"Bloccato",[115,147,120],{},[92,149,150,153,159,163],{},[115,151,152],{},"Un altro sito che lo legge come il tuo utente autenticato",[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],{},"Leggi due volte l'ultima riga, perché è lì che il consiglio generico crolla. Un\nwildcard semplice non può essere usato per leggere dati che appartengono al tuo\nvisitatore autenticato. I browser rifiutano quella combinazione senza appello, e\nla guida CORS di MDN lo dice chiaramente: se una richiesta porta un cookie e la\nrisposta torna con ",[14,172,173],{},"Access-Control-Allow-Origin: *",", il browser blocca l'accesso\nalla risposta e segnala un errore CORS nella console. Così è proprio il\nwildcard, tra tutte le cose, a rendere impossibile quel particolare attacco.",[10,176,177],{},"La colonna che invece consegna i dati di un utente autenticato è la terza, e\nrichiede che il server scriva l'indirizzo del chiamante stesso dentro la propria\nrisposta.",[27,179,181],{"id":180},"limpostazione-cors-che-è-davvero-pericolosa","L'impostazione CORS che è davvero pericolosa",[10,183,184,185,188,189,192],{},"Un server che legge l'header ",[14,186,187],{},"Origin"," dalla richiesta, scrive quello stesso\nvalore nella propria risposta e ci manda insieme\n",[14,190,191],{},"Access-Control-Allow-Credentials: true",".",[10,194,195],{},"Nessuno se lo propone. Arriva alla fine di un pomeriggio passato a provare a far\nfunzionare un wildcard con richieste autenticate e a scoprire che non funzionerà\nmai. Rimandare indietro come eco l'origine che ha chiesto sembra la via\nd'uscita: ogni sito che dovrebbe essere ammesso lo è, gli errori in console\nfiniscono, la funzionalità va in produzione. Quello che il server sta dicendo in\nrealtà è che decide il chiamante, e questo include una pagina che nessuno ha\nancora scritto.",[10,197,198,199,201],{},"Ecco che cosa permette. La tua cliente ha fatto l'accesso alla tua app, con un\ncookie di sessione nel suo browser. In un'altra scheda apre un sito che non ha\nniente a che vedere con te. Il codice di quel sito chiede alla tua API il suo\naccount. Il suo browser allega il cookie, perché allegare cookie è quello che\nfanno i browser. Il tuo server legge un ",[14,200,187],{}," di cui non ha mai sentito\nparlare, lo timbra nella risposta come permesso e aggiunge che le credenziali\nvanno bene. Il browser controlla, trova una corrispondenza e consegna i dati\ndella tua cliente a una pagina che lei non sapeva li stesse leggendo.",[67,203],{"alt":204,"caption":205,"src":206},"Una richiesta lascia un sito sconosciuto portando con sé un cartellino rosso con un nome e un cookie. Il server copia quello stesso cartellino rosso nel campo del permesso della propria risposta. Il browser confronta i due cartellini, li trova uguali e lascia passare i dati fino alla pagina.","Il chiamante fornisce il nome, e il server scrive quel nome sul lasciapassare. Chi chiede è in lista, ed è questo a rendere questo caso diverso da un wildcard.","\u002Fblog\u002Fcors-wildcard-security-risk\u002Fthe-echoed-origin-1600x680.png",[10,208,209],{},"Nella nostra scansione di agosto 2026 questo è comparso su 61 delle 30.926 app\nin cui il controllo è riuscito a ottenere una risposta. Dei tre rilievi CORS, è\nl'unico che arriva a dati che stanno dietro un login.",[27,211,213],{"id":212},"quanto-spesso-compare-un-wildcard-e-chi-lo-decide","Quanto spesso compare un wildcard, e chi lo decide",[10,215,216],{},"Perlopiù lo decide il tuo builder. Nella stessa scansione, 5.727 di quelle\n30.926 app mandavano un wildcard, e il singolo indicatore migliore per sapere se\nlo fa la tua è la piattaforma che l'ha pubblicata.",[10,218,219],{},"Il controllo CORS ha segnalato almeno un rilievo su 5.418 delle 5.419 app Base44\nin cui ha ottenuto una risposta, e su 8 delle 18.518 app Lovable. Replit sta nel\nmezzo, con 1.129 su 3.037. Uno scarto così ampio è l'aspetto che ha da fuori un\nvalore predefinito dell'hosting: quasi totale su una piattaforma, quasi assente\nsu un'altra, attraverso migliaia di app i cui proprietari non hanno mai\ncoordinato niente.",[10,221,222,223,228],{},"Tre rilievi distinti compongono il controllo CORS su tutte le 30.926 app: un\nwildcard su 5.727 di esse, un indirizzo che risponde con dati e senza login su\n3.852, e la forma dell'origine rimandata come eco su 61. Sommati fanno più del\ncontrollo stesso, perché molte app ne hanno due su tre. Ogni cifra qui viene\n",[224,225,227],"a",{"href":226},"\u002Fresearch\u002Fvibe-coded-app-security-2026","dalla nostra scansione di 30.998 app vibe-coded online",",\nche pubblica ciascuna insieme alla base su cui è stata misurata.",[10,230,231],{},"Su che cosa puoi intervenire si divide allo stesso modo. Il wildcard lo manda\nchi serve la tua app, e per un'app vibe-coded di solito è il builder. Che cosa\ntorna indietro quando uno sconosciuto chiede dati a uno dei tuoi indirizzi è\nstato deciso dentro la tua app, da te o dal builder che scrive codice per tuo\nconto.",[27,233,235],{"id":234},"come-controllare-la-tua-app","Come controllare la tua app",[10,237,238],{},"Due cose da guardare, e la seconda è quella che decide se qualcosa di tutto\nquesto conta.",[10,240,241,244,245,248,249,252,253,256],{},[22,242,243],{},"La tua app manda un wildcard?"," Apri la tua app in produzione, premi F12 per\nfar comparire gli strumenti per sviluppatori del browser, clicca su ",[22,246,247],{},"Network","\ne ricarica la pagina. Clicca sulla prima richiesta dell'elenco e leggi il\npannello ",[22,250,251],{},"Response Headers",". Una riga con ",[14,254,255],{},"access-control-allow-origin: *"," è\nil rilievo. Nessuna riga del genere significa che il tuo server non condivide\nniente tra origini con nessuno.",[10,258,259,262],{},[22,260,261],{},"Che cosa risponde dietro?"," Resta nella scheda Network e ricarica la tua app\nmentre hai fatto l'accesso, tenendo d'occhio le richieste che tornano in JSON.\nQuelli sono gli indirizzi da cui la tua app prende i dati. Copia ogni URL, apri\nuna finestra di navigazione privata così da non avere l'accesso fatto, e\nincollali uno alla volta. Tutto ciò che torna con righe vere, invece che con un\nerrore o una lista vuota, è leggibile da chiunque su internet abbia quell'URL. È\nvero oggi, qualunque cosa dica il tuo header CORS, e resta vero dopo che lo hai\nristretto.",[10,264,265,266,192],{},"La nostra scansione gratuita fa il secondo controllo al posto tuo: legge il\ncodice della tua app in cerca degli indirizzi che chiama, interroga ognuno senza\nlogin e segnala quelli che hanno risposto con dei dati. Ci vogliono circa 20\nsecondi e non serve un account: ",[224,267,269],{"href":268},"\u002F#scan","scansiona la tua app",[10,271,272,273,192],{},"Se la tua app parla con Supabase direttamente dal browser, c'è un terzo posto da\nguardare, perché le regole su ogni tabella decidono chi può leggere quali righe\ne ",[224,274,276],{"href":275},"\u002Fblog\u002Fsupabase-rls-on-but-table-still-public","attivarle non equivale a essere protetti",[27,278,280],{"id":279},"che-cosa-fare-adesso","Che cosa fare adesso",[282,283,284],"key-takeaways",{},[285,286,287,291,294,297,303],"ul",{},[288,289,290],"li",{},"Prendi un rilievo di wildcard come una domanda su che cosa c'è dietro l'header. Sull'indirizzo da cui viene servita la tua app, di solito permette di leggere file che ogni visitatore scarica comunque.",[288,292,293],{},"Esci dall'accesso e apri ogni indirizzo di dati che la tua app chiama. Tutto ciò che restituisce righe vere a un browser senza accesso è pubblico per chiunque, qualunque cosa dica l'header.",[288,295,296],{},"Correggi un indirizzo aperto sull'indirizzo stesso: richiedi un login e rispondi a uno sconosciuto con un 401. Restringere l'header CORS lo lascia raggiungibile da tutto tranne che dalle pagine web degli altri.",[288,298,299,300,302],{},"Se il tuo server rimanda indietro come eco l'origine che ha chiesto e manda ",[14,301,191],{},", sostituiscilo oggi con un elenco dei tuoi domini. È l'unico caso qui che lascia a un altro sito leggere dati come il tuo utente autenticato.",[288,304,305],{},"Se l'header arriva dall'hosting del tuo builder e non puoi cambiarlo, spendi il tempo sugli endpoint. È lì che stanno i tuoi dati.",[10,307,308,309,192],{},"L'abitudine che vale la pena tenere è il giro senza accesso sui tuoi indirizzi\ndi dati, perché ogni nuova funzionalità ne aggiunge uno e sullo schermo non\ncambia niente quando uno di loro inizia a rispondere. Reeve Care rilancia questa\nscansione contro la tua app in produzione a intervalli regolari e ti scrive\nquando un risultato peggiora:\n",[224,310,312],{"href":311},"\u002F#pricing","che cosa sorveglia e quanto costa",[10,314,315,316,320,321,325],{},"Se preferisci sistemare tutto in una sola seduta, la\n",[224,317,319],{"href":318},"\u002Fchecklist","checklist di sicurezza da 10 minuti"," copre questo insieme al resto\ndi ciò che un'app appena lanciata tende a lasciare aperto, e\n",[224,322,324],{"href":323},"\u002Fblog\u002Fwhich-api-keys-are-safe-in-your-frontend","quali chiavi sono sicure nel tuo frontend","\nè l'altra metà della domanda con cui di solito arriva la gente.",{"title":327,"searchDepth":328,"depth":328,"links":329},"",3,[330,332,333,334,335,336,337],{"id":29,"depth":331,"text":30},2,{"id":52,"depth":331,"text":53},{"id":77,"depth":331,"text":78},{"id":180,"depth":331,"text":181},{"id":212,"depth":331,"text":213},{"id":234,"depth":331,"text":235},{"id":279,"depth":331,"text":280},"Basi della sicurezza","\u002Fblog\u002Fcors-wildcard-security-risk\u002Fcover-1200x630.png","Sei chiamanti diversi raggiungono un solo server, e la stessa risposta torna indietro verso ognuno di loro.","Un wildcard CORS è un rischio di sicurezza? Di solito è il valore predefinito del tuo builder e non consegna nulla che il tuo server non desse già a chiunque.",false,"md",[345,348,351,354,357],{"q":346,"a":347},"La scansione dice che la mia API è aperta a qualsiasi sito. Devo sistemarlo?","Guarda prima che cosa risponde dietro. Un wildcard sull'indirizzo da cui viene servita la tua app di solito permette di leggere le tue pagine, le tue immagini e il tuo codice compilato, e tutto questo ogni visitatore lo scarica comunque. Sistemalo quando un indirizzo dietro quell'header restituisce dati veri a qualcuno che non ha fatto l'accesso, e sistemalo su quell'indirizzo richiedendo un login.",{"q":349,"a":350},"Restringere CORS al mio dominio rende privata la mia API?","No. CORS è una regola che i browser applicano a sé stessi, quindi governa soltanto codice in esecuzione sulla pagina web di qualcun altro. Uno script, un comando da terminale o uno scraper mandano la stessa richiesta e leggono la stessa risposta, perché nessuno di loro consulta l'header. Se un indirizzo restituisce i tuoi dati senza login, lo fa per tutti, qualunque cosa dica l'header.",{"q":352,"a":353},"Un altro sito può leggere i dati dei miei utenti autenticati per colpa di un wildcard?","Con un wildcard semplice no. I browser rifiutano quella combinazione: la guida CORS di MDN afferma che, quando una richiesta porta con sé un cookie e la risposta torna con Access-Control-Allow-Origin impostato sul wildcard, il browser blocca l'accesso alla risposta e registra un errore CORS. La versione che invece funziona è un server che rimanda indietro come eco l'origine che ha chiesto, insieme ad Access-Control-Allow-Credentials impostato su true.",{"q":355,"a":356},"Come cambio l'header CORS su un'app Lovable o Base44?","Spesso non puoi, perché l'header lo manda l'hosting su cui pubblica il tuo builder e vale per ogni app di quella piattaforma. Vale la pena saperlo prima di dedicarci una settimana. Quello che puoi sempre cambiare è ciò che i tuoi endpoint restituiscono a una richiesta senza login, ed è comunque lì che la correzione va fatta.",{"q":358,"a":359},"La scansione ha segnalato anche endpoint API aperti. È lo stesso rilievo?","È un altro, e il più grave dei due. Un wildcard descrive chi può leggere una risposta. Un endpoint aperto significa che la risposta conteneva i tuoi dati ed è arrivata senza che nessuno facesse l'accesso. Il secondo vale allo stesso modo per un browser, per uno script e per uno sconosciuto con l'URL, e restringere il tuo header CORS non ne cambia nulla.","\u002Fblog\u002Fcors-wildcard-security-risk\u002Fcard-800x500.png",[362,363,364,365,366,367],"wildcard cors rischio sicurezza","access-control-allow-origin wildcard","il wildcard cors è pericoloso","configurazione cors sbagliata","api aperta a qualsiasi sito","access-control-allow-credentials true",{},true,"\u002Fblog\u002Fcors-wildcard-security-risk","2026-08-26",{"title":5,"description":341},"blog\u002Fcors-wildcard-security-risk",[375,376,377],"Un wildcard CORS è un rischio di sicurezza solo quando dietro di esso risponde qualcosa di privato. Da solo permette di leggere cose che chiunque poteva già scaricare.","L'header è un'istruzione per il browser del tuo visitatore e arriva dopo che la risposta è già partita. Fuori da un browser nessuno lo legge, quindi restringerlo lascia un endpoint aperto esattamente com'era.","La forma che merita una serata è un server che rimanda indietro come eco il sito che sta chiedendo e in più consente le credenziali. Quella sì lascia che un altro sito legga dati come il tuo utente autenticato.","kwpgVCVBsfpmBE0OAAp1on_-WugfdtZgCjlhYr3KPAs",1787826050994]