Un endpoint API aperto è un problema di sicurezza? Leggi il JSON

La tua scansione è tornata con una riga che non si legge come un verdetto: alcuni endpoint API rispondono senza login. Magari qualcuno te l'ha detto in modo più diretto, parlando di un endpoint API aperto. Sotto c'è un indirizzo, ed è piuttosto probabile che tu non lo riconosca.

Ecco la parte che guida dopo guida racconta male: il consiglio abituale per questo rilievo è mettere un login davanti al tuo endpoint, e nella maggior parte delle app che abbiamo scansionato non c'è nessun endpoint tuo davanti a cui metterlo. Sette su dieci di quelli che abbiamo trovato appartengono alla piattaforma su cui l'app è stata pubblicata. Leggere questo rilievo comincia quindi dal capire di chi è l'indirizzo, e la risposta di solito si vede già nella prima riga di quello che torna.

Che cosa significa un endpoint API aperto nel tuo report

Significa che un percorso scritto nel codice della tua app ha risposto a una richiesta che non portava alcun login, e che quello che è tornato era JSON.

Tre passaggi, e nessuno di questi è astuto. Carichiamo la tua app in un browser come fa un visitatore, e leggiamo il codice che quel browser ha scaricato. Lì dentro ci sono gli indirizzi che la tua app chiama quando le servono dei dati. Poi chiediamo dati a ciascuno, senza account, senza cookie e senza chiave. Se un indirizzo risponde con JSON che non è un messaggio di errore, finisce nel report.

Questo registra che cosa è successo. Non è un giudizio sui dati, perché niente che stia fuori dalla tua app può capire se un elenco di cose è un elenco di cose pubbliche. Per questo il rilievo è formulato così: questi endpoint hanno restituito dati senza alcuna autenticazione, può essere voluto per dati pubblici, controlla che nessuno esponga informazioni private.

Il report ti consegna quindi un elenco di indirizzi da aprire. Ognuno di loro va aperto in un browser disconnesso, e sono le prime righe della risposta a chiudere la questione.

Ogni endpoint API aperto è un problema di sicurezza?

No. Ce ne sono tre tipi, e solo il terzo è un problema.

Pensa a un condominio. Certe cose lì dentro sono fatte per chiunque entri: gli orari accanto alla porta, le uscite di sicurezza, l'avviso della manutenzione dell'ascensore di martedì. Da qualche altra parte nello stesso palazzo c'è uno schedario con i dati degli inquilini. Dal corridoio, una bacheca e uno schedario non chiuso a chiave sono entrambi mobili che si possono aprire, e l'unico modo per distinguerli è leggere che cosa c'è scritto sulla carta.

La prima riga è una bacheca che ha avvitato al muro qualcun altro. La seconda è una bacheca che hai appeso tu apposta. La terza è lo schedario, ed è aperto da tanto quanto esiste l'indirizzo.

Come controllare che cosa restituiscono i tuoi endpoint

Aprili uno a uno da disconnesso e leggi quello che arriva. La lettura richiede più tempo di quanto il rilievo lasci intendere, ed è l'unico passaggio che risponde alla domanda.

Trova gli indirizzi. Apri la tua app in produzione, premi F12 per far comparire gli strumenti per sviluppatori del browser, clicca su Rete e ricarica la pagina. Scorri le richieste che tornano come JSON. Quelli sono gli indirizzi da cui la tua app prende i dati, e l'elenco del report ne è un sottoinsieme.

Interroga ciascuno da sconosciuto. Copia una URL, apri una finestra di navigazione in incognito così da essere disconnesso, e incollala. Quello che vedi è esattamente quello che a quell'indirizzo vede chiunque su internet.

Leggi le prime righe. Tre cose possono tornare:

• Un errore, un rifiuto, oppure []. L'indirizzo vuole un login, oppure non c'è niente lì dentro per un chiamante disconnesso. Vai avanti.
• Impostazioni. Flag, interruttori, un colore, l'elenco delle funzioni attive, un numero di versione. Nessuno viene nominato e niente viene descritto. Vai avanti.
• Righe. Un indirizzo email, il nome di una persona, il totale di un ordine, il testo di un messaggio, un numero di telefono. Fermati qui, è questo.

Se trovi delle righe, prova a cambiare un numero nella URL prima di chiudere la scheda. Un indirizzo che consegna la scheda di una persona su id=1 e quella di un'altra su id=2 le sta consegnando tutte, e vale la pena saperlo prima di decidere quanto sia urgente.

La nostra scansione gratuita fa i primi due passaggi al posto tuo: legge nel codice della tua app gli indirizzi che chiama, interroga ciascuno senza login, ed elenca quelli che hanno risposto con dei dati. Dura una ventina di secondi e non richiede alcun account: scansiona la tua app. Il terzo passaggio è tuo, perché sei l'unica persona che sa se un nome in quell'elenco è un cliente vero.

La maggior parte di quelli che abbiamo trovato è della piattaforma

Nella nostra rilevazione di agosto 2026, 3.852 delle 30.926 app in cui questo controllo è riuscito a ottenere una risposta avevano almeno un indirizzo che risponde senza login. Di queste, 2.705 erano app Base44, e su Base44 l'indirizzo è quasi sempre lo stesso.

È /api/consent/config, le impostazioni dei cookie della piattaforma. A settembre abbiamo riaperto un campione di app Base44 segnalate e l'unico indirizzo che ha risposto era quello. Restituisce impostazioni, è identico da un'app all'altra, e lì dentro non ci sono i dati di nessuno. Lo scanner lo sta riportando correttamente e il proprietario non ha niente da correggere.

Una piattaforma manca da quella tabella apposta. A Replit va un blocco grosso dei rilievi rimanenti, e nessuno ne ha riaperto un campione come abbiamo fatto con quelli di Base44, quindi non sappiamo ancora di chi siano quegli indirizzi. Pubblicare un numero come problema del proprietario prima che qualcuno l'abbia guardato è esattamente il modo in cui un'impostazione di piattaforma di Base44 diventa una statistica sui proprietari negligenti. Ogni numero qui sopra viene dalla nostra scansione di 30.998 app vibe-coded in produzione, che pubblica ciascuno insieme alla base su cui è stato misurato.

Leggi insieme i due estremi di quella tabella, perché la distanza è la parte utile. Su Lovable sono 8 app su 18.518, e su v0 nessuna. Quelle app non hanno un piccolo server tutto loro: la pagina parla con Supabase direttamente dal browser, quindi non c'è da nessuna parte un /api/… tuo che questo controllo possa trovare. Quello che protegge i dati in un'app così sono le regole su ciascuna tabella, ed è un rilievo diverso con un suo modo di andare storto.

Quando il JSON sono impostazioni e quando sono persone

Una domanda decide: c'è qualcosa nella risposta che descrive una persona?

Le impostazioni descrivono la tua app. Un flag che dice se la modalità scura è attiva, l'elenco delle valute che accetti, la versione di qualcosa, il testo di un banner dei cookie. Pubblicare quello rivela come è configurata la tua app, e la tua app gira comunque davanti a tutti.

Le righe descrivono i tuoi utenti. Un nome, un indirizzo email, che cosa ha comprato qualcuno, che cosa ha scritto, dove abita. Quella non è una frase sulla configurazione, è il contenuto dello schedario, e conta per quanto è ordinario portarselo via. Non c'è nessuna effrazione. L'indirizzo è una riga di testo che funziona in qualsiasi browser, quindi finisce incollato in una chat di gruppo, salvato negli appunti di qualcuno, e scaricato a intervalli da uno script che nessuno sta guardando.

Chiuderne uno, e perché rinominare il percorso non lo chiude

Chiedi un login all'indirizzo, e rispondi 401 a chi chiama senza averlo.

La correzione è tutta qui, e va all'indirizzo e da nessun'altra parte. Tre cose che sembrano la correzione e non lo sono:

• Rinominare il percorso, o toglierlo dal codice. Di questa bisogna diffidare, perché il rilievo sparisce. Chi aveva già la URL ce l'ha ancora, sta nelle cronologie dei browser e nei log del server, e lo schedario è ancora aperto, solo senza l'etichetta davanti.
• Restringere l'header CORS. Quello decide quali altri siti possono leggere una risposta dentro al browser di qualcuno, e nient'altro lo consulta. Uno script o un terminale legge lo stesso indirizzo in entrambi i casi, ed è per questo che il rilievo del wildcard è un'altra domanda.
• Filtrare nell'app. Se la pagina nasconde le righe che non dovrebbe mostrare, l'indirizzo continua a mandarle. Il filtro deve avvenire prima che la risposta esca.

C'è una quarta opzione, e su una pagina pubblica è spesso la migliore: smettere di avere l'endpoint. Se i dati servono solo alla tua pagina, la pagina può riceverli mentre viene costruita, e l'indirizzo esce dal tuo codice insieme a loro.

Che aspetto ha la correzione nel codice

Due cose, nell'handler che risponde all'indirizzo: capire chi sta chiedendo, e fermarsi se la risposta è nessuno.

Forse non scriverai mai queste righe di persona, e va benissimo. Leggile lo stesso, perché sono quello con cui verifichi che il tuo builder abbia davvero fatto ciò che gli hai chiesto. Questa è la forma di prima, quella che la scansione ha trovato:

app.get('/api/orders', async (req, res) => {
  const orders = await db.orders.findMany()
  res.json(orders)
})

E dopo:

app.get('/api/orders', async (req, res) => {
  const user = await getUserFromRequest(req)
  if (!user) {
    return res.status(401).json({ error: 'Not signed in' })
  }

  const orders = await db.orders.findMany({ where: { userId: user.id } })
  res.json(orders)
})

Sono cambiate due cose e contano entrambe. Il 401 è la porta. Il where è il motivo per cui la porta vale la pena: senza, un visitatore autenticato può leggere gli ordini di tutti gli altri clienti, che è un pubblico più piccolo per gli stessi dati e resta comunque quello sbagliato.

Sulle Edge Function di Supabase, leggi la configurazione prima di scrivere qualsiasi cosa. Le Edge Function controllano da sole il token di chi chiama: la documentazione di configurazione di Supabase mette verify_jwt a true di default, quindi una funzione che risponde agli sconosciuti è una funzione in cui qualcuno l'ha disattivato, con una riga in supabase/config.toml oppure pubblicando con --no-verify-jwt:

[functions.orders]
verify_jwt = false

Se la tua funzione deve essere privata, cancella quelle due righe e ripubblica. Lasciale solo dove l'endpoint deve davvero rispondere a chiunque, che è il caso che la documentazione di Supabase stessa prende come esempio: un webhook di pagamento. Dentro la funzione, l'SDK attuale ti dà un client già limitato alla persona che ha chiamato:

import { withSupabase } from 'npm:@supabase/server'

export default {
  fetch: withSupabase({ auth: 'user' }, async (_req, ctx) => {
    const { data } = await ctx.supabase.from('orders').select()
    return Response.json(data)
  }),
}

ctx.supabase gira come chi ha chiamato, quindi sono le tue regole di sicurezza a livello di riga a decidere che cosa torna, cioè la stessa protezione su cui si appoggia il resto della tua app e la cosa che vale la pena controllare a parte.

Il prompt da incollare nel tuo builder

Se costruisci in Lovable, Bolt, Cursor, Replit o v0, dagli questo. Lascialo in inglese, in qualunque lingua tu stia leggendo, perché è la lingua in cui questi strumenti ragionano, e sostituisci le due parti fra parentesi quadre con quello che dice il tuo report:

A security scan of [my-app.com] found these API endpoints answer
without any authentication: [/api/orders, /api/users].

Please look at each one and decide whether it is meant to be public.
For the ones that are not, require a valid session or API token and
return 401 otherwise. Make sure each one returns only the rows that
belong to the person asking, not the whole table filtered in the UI.
For any that must stay open, make sure they return only non-sensitive
data and add rate limiting so they cannot be abused.

Tell me what you changed for each endpoint, and do not rename or
remove the paths.

Quell'ultima frase è lì apposta. Quando gli si chiede di far sparire un rilievo, un modello a volte prende la strada più corta e sposta l'indirizzo, che è l'unico risultato che alla scansione successiva sembra un successo e non cambia niente.

Che cosa fare adesso

Gli indirizzi di questo elenco li ha scritti qualcuno che allora sapeva che cosa ci fosse dietro, e quello che cambia è proprio quello che c'è dietro. Reeve Care ripassa questa scansione sulla tua app in produzione a intervalli regolari e ti manda una email quando un risultato peggiora, che è esattamente il caso che il giro da disconnesso qui sopra non può prendere: che cosa sorveglia e quanto costa.

Se preferisci sistemare tutto in una volta sola, la checklist di sicurezza in 10 minuti copre questo insieme al resto di ciò che un'app appena lanciata tende a lasciare aperto, e quali chiavi sono sicure nel frontend è l'altro rilievo con cui la gente arriva di solito.