Security Blog

View Source, Copia la Chiave, Possiedi Tutto

#47

October 2, 2026 · By Marketing team

← All posts

Un ricercatore ha aperto il sorgente della pagina di ClickUp, trovato una API key hardcoded nel JavaScript e usata per ottenere 959 indirizzi email e 3.165 feature flag interni con una sola richiesta. La chiave non aveva scope, non aveva rate limit e non aveva scadenza.

Un ricercatore di sicurezza è andato su clickup.com. Ha aperto il sorgente della pagina. Ha trovato una API key hardcoded nel JavaScript. L'ha copiata. Ha inviato una sola richiesta GET.

Ha ottenuto 959 indirizzi email e 3.165 feature flag interni. Dipendenti di Home Depot. Fortinet. Autodesk. Tenable. Rakuten. Mayo Clinic.

Una stringa. Una richiesta. Tutto.

Come è possibile

Qualcuno aveva bisogno che il frontend chiamasse una API. La API richiedeva autenticazione. Così ha messo la chiave nel JavaScript. Si rilascia, si va avanti, sprint successivo.

Non è un attacco sofisticato. Non c'è exploit, non c'è zero-day, non c'è social engineering. C'è view-source: e curl. Un browser e un terminale. Il tipo di cosa che fa uno stagista curioso il primo giorno.

La chiave non aveva scope — poteva accedere a tutto ciò che la API esponeva. Nessun rate limit — una richiesta restituiva tutto. Nessuna scadenza — la chiave funzionava finché qualcuno non se ne accorgeva. Nessun secondo fattore — il possesso della stringa era l'unico cancello.

L'aspetto economico

Si parla di esposizione dei dati. Parliamo di quanto valgono questi dati.

959 indirizzi email aziendali di aziende del Fortune 500. È una lista di bersagli per spear-phishing per cui gli attori di minaccia pagano. Nomi, ruoli, e il fatto che queste aziende usano ClickUp — è il contesto di social engineering che fa funzionare il phishing.

3.165 feature flag interni. È una roadmap. Dice ai concorrenti cosa sta costruendo ClickUp, cosa sta testando, cosa c'è dietro un gate. Dice agli attaccanti quali funzionalità sono a metà e probabilmente vulnerabili.

Non è un incidente di privacy. È una fuga di business intelligence.

Perché continua a succedere

Questo è il quarto incidente di credenziali nel sorgente che raccontiamo questo mese. La CLI di Bitwarden ha avuto credenziali raccolte perché erano file in chiaro. Le variabili d'ambiente di Vercel erano decifrabili perché il flag "sensitive" non era impostato per impostazione predefinita. Uno sviluppatore ha perso 634 password di Chrome perché la chiave di decifratura era sullo stesso disco.

Lo schema è sempre lo stesso: una credenziale esiste come stringa — in un file, in una variabile, nel sorgente della pagina — e qualcosa la legge. Il "qualcosa" cambia. Lo schema no.

Le API key nel JavaScript sono la versione più grave perché non serve alcun attacco. La chiave è pubblicata. Viene servita a ogni visitatore. Il browser la scarica, la rende e la mostra a chiunque faccia clic col pulsante destro.

Cosa sarebbe dovuto cambiare

La chiamata API non avrebbe mai dovuto essere autenticata con una chiave statica lato client. Le opzioni:

  • Backend proxy. Il frontend chiama il proprio backend, che detiene la chiave lato server e fa da proxy per la chiamata API. La chiave non arriva mai al browser.
  • Token con scope di sessione. Il frontend ottiene, dopo l'autenticazione, un token a breve durata e con scope ristretto. Scade. Può fare solo ciò che all'utente autenticato è consentito. Non è una chiave padrona.
  • Nessuna chiave. Se i dati sono pubblici, servirli senza autenticazione. Se non sono pubblici, non servirli a JavaScript non autenticato.

Hardcodare una API key nel codice lato client è come mettere la chiave di casa sotto lo zerbino e pubblicare il proprio indirizzo.

Il problema del ciclo di vita delle credenziali

Questa chiave di ClickUp è probabilmente stata creata una volta, incollata in un file JavaScript, committata in un repository, distribuita in produzione e mai più presa in considerazione. Nessuno l'ha ruotata. Nessuno ne ha definito lo scope. Nessuno ne ha impostato una scadenza. Nessuno ha monitorato a cosa accedesse.

È il ciclo di vita della maggior parte delle API key nella maggior parte delle organizzazioni. Create di fretta, incollate dove servono, dimenticate. Si accumulano tra codebase, file di configurazione, pipeline CI/CD e, a quanto pare, sorgente delle pagine — ognuna una porta che non si chiude mai.

La domanda non è se la sua organizzazione abbia una chiave così. La domanda è quante ne abbia, e se si accorgerebbe se qualcuno ne copiasse una oggi.