Reeve Basi della sicurezza
Un wildcard CORS è un rischio di sicurezza? Quasi mai.
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.
In breve
- 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.
La tua scansione è tornata con una riga che si legge come un allarme: la tua API
è aperta a qualsiasi sito. Oppure qualcuno di tecnico ha guardato che cosa
rimanda il tuo server e ti ha detto che la tua app ha un wildcard CORS, cioè il
carattere *, che a quanto pare significa tutti.
Ecco la parte che guida dopo guida racconta male: il wildcard non è quasi mai ciò che ha aperto la tua API. È un'istruzione che il tuo server allega alle proprie risposte, indirizzata ai browser di persone che stanno su altri siti, e arriva dopo che la risposta è già uscita. Restringerlo impedisce alla pagina di un altro sito di leggere i tuoi dati. Non fa nulla contro chi li legge senza alcun browser.
Un wildcard CORS è un rischio di sicurezza?
Da solo, quasi mai. Lo diventa nel momento in cui dietro risponde qualcosa di privato.
Il wildcard è il valore * in un header di risposta chiamato
Access-Control-Allow-Origin, e significa che il codice di qualsiasi sito può
leggere quella particolare risposta. Sembra un'affermazione su chi può arrivare
ai tuoi dati. È un'affermazione su chi può leggere ciò che il tuo server ha già
mandato.
L'indirizzo che una scansione controlla è quello da cui viene servita la tua app. Sulla maggior parte dei builder quell'indirizzo distribuisce le tue pagine, le tue immagini e il tuo codice compilato, e tutto questo va a ogni visitatore per come è progettato. Un wildcard lì sopra concede il permesso di leggere file che chiunque poteva già scaricare aprendo il tuo sito.
Il rilievo è quindi una domanda e non un verdetto, e la domanda è che cosa sta dietro l'header. Se la risposta è la tua home page, non è successo niente. Se la risposta è un elenco dei tuoi clienti, quell'elenco era già raggiungibile da chiunque avesse l'indirizzo.
Che cosa fa davvero Access-Control-Allow-Origin
Dice al browser del tuo visitatore se la pagina che ha sullo schermo può guardare una risposta che il tuo server ha già mandato.
L'ordine è tutto, e va al contrario di come se lo immagina quasi chiunque. Una
pagina su un altro sito esegue un pezzo di codice che chiede dati alla tua app.
La richiesta parte. Il tuo server la riceve, esegue quello che deve eseguire e
rimanda indietro la risposta per intero. Solo a quel punto il browser legge
l'header di quella risposta e decide se consegnare il contenuto alla pagina che
lo ha chiesto. La guida CORS di MDN lo mette in una riga: il server deve dare il
proprio assenso con Access-Control-Allow-Origin per condividere la risposta
con lo script.
I tuoi dati hanno lasciato l'edificio in entrambi i casi. Quello che l'header decide è se un preciso pezzo di codice, in esecuzione dentro il browser di una precisa persona, arriva a vederli.
Il browser è l'unica cosa in questa storia che legga l'header. Uno script su un server, uno strumento da riga di comando, uno scraper, un'app per telefono: nessuno di loro lo consulta, perché è stato scritto per un browser e di browser non ce n'è. Mandano la stessa richiesta, ottengono la stessa risposta e ne leggono ogni byte.
Restringere CORS non rende privato un endpoint aperto
Perché CORS vive dentro i browser, e chi si sta servendo dei tuoi dati non ha motivo di usarne uno.
È la parte che costa un pomeriggio. Si vede il rilievo del wildcard, si restringe l'header al proprio dominio, si ridistribuisce, si riscansiona, e l'indirizzo che distribuiva righe di clienti continua a distribuire righe di clienti. Lo ha sempre fatto. L'unico chiamante che si sia mai fermato era la pagina web di qualcun altro.
| Che cosa prova a fare qualcuno | Wildcard * | Solo il tuo dominio | Qualsiasi origine rimandata come eco, credenziali ammesse |
|---|---|---|---|
| Aprire l'indirizzo in una scheda del browser | Funziona | Funziona | Funziona |
| Leggerlo da uno script o da un terminale | Funziona | Funziona | Funziona |
| La pagina di un altro sito che lo legge | Funziona | Bloccato | Funziona |
| Un altro sito che lo legge come il tuo utente autenticato | Bloccato | Bloccato | Funziona |
Leggi due volte l'ultima riga, perché è lì che il consiglio generico crolla. Un
wildcard semplice non può essere usato per leggere dati che appartengono al tuo
visitatore autenticato. I browser rifiutano quella combinazione senza appello, e
la guida CORS di MDN lo dice chiaramente: se una richiesta porta un cookie e la
risposta torna con Access-Control-Allow-Origin: *, il browser blocca l'accesso
alla risposta e segnala un errore CORS nella console. Così è proprio il
wildcard, tra tutte le cose, a rendere impossibile quel particolare attacco.
La colonna che invece consegna i dati di un utente autenticato è la terza, e richiede che il server scriva l'indirizzo del chiamante stesso dentro la propria risposta.
L'impostazione CORS che è davvero pericolosa
Un server che legge l'header Origin dalla richiesta, scrive quello stesso
valore nella propria risposta e ci manda insieme
Access-Control-Allow-Credentials: true.
Nessuno se lo propone. Arriva alla fine di un pomeriggio passato a provare a far funzionare un wildcard con richieste autenticate e a scoprire che non funzionerà mai. Rimandare indietro come eco l'origine che ha chiesto sembra la via d'uscita: ogni sito che dovrebbe essere ammesso lo è, gli errori in console finiscono, la funzionalità va in produzione. Quello che il server sta dicendo in realtà è che decide il chiamante, e questo include una pagina che nessuno ha ancora scritto.
Ecco che cosa permette. La tua cliente ha fatto l'accesso alla tua app, con un
cookie di sessione nel suo browser. In un'altra scheda apre un sito che non ha
niente a che vedere con te. Il codice di quel sito chiede alla tua API il suo
account. Il suo browser allega il cookie, perché allegare cookie è quello che
fanno i browser. Il tuo server legge un Origin di cui non ha mai sentito
parlare, lo timbra nella risposta come permesso e aggiunge che le credenziali
vanno bene. Il browser controlla, trova una corrispondenza e consegna i dati
della tua cliente a una pagina che lei non sapeva li stesse leggendo.
Nella nostra scansione di agosto 2026 questo è comparso su 61 delle 30.926 app in cui il controllo è riuscito a ottenere una risposta. Dei tre rilievi CORS, è l'unico che arriva a dati che stanno dietro un login.
Quanto spesso compare un wildcard, e chi lo decide
Perlopiù lo decide il tuo builder. Nella stessa scansione, 5.727 di quelle 30.926 app mandavano un wildcard, e il singolo indicatore migliore per sapere se lo fa la tua è la piattaforma che l'ha pubblicata.
Il controllo CORS ha segnalato almeno un rilievo su 5.418 delle 5.419 app Base44 in cui ha ottenuto una risposta, e su 8 delle 18.518 app Lovable. Replit sta nel mezzo, con 1.129 su 3.037. Uno scarto così ampio è l'aspetto che ha da fuori un valore predefinito dell'hosting: quasi totale su una piattaforma, quasi assente su un'altra, attraverso migliaia di app i cui proprietari non hanno mai coordinato niente.
Tre rilievi distinti compongono il controllo CORS su tutte le 30.926 app: un wildcard su 5.727 di esse, un indirizzo che risponde con dati e senza login su 3.852, e la forma dell'origine rimandata come eco su 61. Sommati fanno più del controllo stesso, perché molte app ne hanno due su tre. Ogni cifra qui viene dalla nostra scansione di 30.998 app vibe-coded online, che pubblica ciascuna insieme alla base su cui è stata misurata.
Su che cosa puoi intervenire si divide allo stesso modo. Il wildcard lo manda chi serve la tua app, e per un'app vibe-coded di solito è il builder. Che cosa torna indietro quando uno sconosciuto chiede dati a uno dei tuoi indirizzi è stato deciso dentro la tua app, da te o dal builder che scrive codice per tuo conto.
Come controllare la tua app
Due cose da guardare, e la seconda è quella che decide se qualcosa di tutto questo conta.
La tua app manda un wildcard? Apri la tua app in produzione, premi F12 per
far comparire gli strumenti per sviluppatori del browser, clicca su Network
e ricarica la pagina. Clicca sulla prima richiesta dell'elenco e leggi il
pannello Response Headers. Una riga con access-control-allow-origin: * è
il rilievo. Nessuna riga del genere significa che il tuo server non condivide
niente tra origini con nessuno.
Che cosa risponde dietro? Resta nella scheda Network e ricarica la tua app mentre hai fatto l'accesso, tenendo d'occhio le richieste che tornano in JSON. Quelli sono gli indirizzi da cui la tua app prende i dati. Copia ogni URL, apri una finestra di navigazione privata così da non avere l'accesso fatto, e incollali uno alla volta. Tutto ciò che torna con righe vere, invece che con un errore o una lista vuota, è leggibile da chiunque su internet abbia quell'URL. È vero oggi, qualunque cosa dica il tuo header CORS, e resta vero dopo che lo hai ristretto.
La nostra scansione gratuita fa il secondo controllo al posto tuo: legge il codice della tua app in cerca degli indirizzi che chiama, interroga ognuno senza login e segnala quelli che hanno risposto con dei dati. Ci vogliono circa 20 secondi e non serve un account: scansiona la tua app.
Se la tua app parla con Supabase direttamente dal browser, c'è un terzo posto da guardare, perché le regole su ogni tabella decidono chi può leggere quali righe e attivarle non equivale a essere protetti.
Che cosa fare adesso
Cosa fare
- 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.
- 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.
- 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.
- Se il tuo server rimanda indietro come eco l'origine che ha chiesto e manda
Access-Control-Allow-Credentials: true, 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. - Se l'header arriva dall'hosting del tuo builder e non puoi cambiarlo, spendi il tempo sugli endpoint. È lì che stanno i tuoi dati.
L'abitudine che vale la pena tenere è il giro senza accesso sui tuoi indirizzi di dati, perché ogni nuova funzionalità ne aggiunge uno e sullo schermo non cambia niente quando uno di loro inizia a rispondere. Reeve Care rilancia questa scansione contro la tua app in produzione a intervalli regolari e ti scrive quando un risultato peggiora: che cosa sorveglia e quanto costa.
Se preferisci sistemare tutto in una sola seduta, la checklist di sicurezza da 10 minuti copre questo insieme al resto di ciò che un'app appena lanciata tende a lasciare aperto, e quali chiavi sono sicure nel tuo frontend è l'altra metà della domanda con cui di solito arriva la gente.
FAQ
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.
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.
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.
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.
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.