𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗔𝘂𝗱𝗶𝘁 𝗥𝗲𝘀𝘂𝗹𝘁𝘀: 𝗪𝗵𝘆 𝗜 𝗳𝗲𝗹 𝗲𝗺𝗯𝗮𝗿𝗿𝗮𝘀𝘀𝗲𝗱
Recentemente ho eseguito un audit di sicurezza su tutti i miei progetti secondari. Questo include il mio backend FastAPI, i bot di Telegram, la PWA e le app Streamlit.
Pensavo che il mio codice fosse sicuro perché ero stato attento. Mi sbagliavo.
Condivido questi bug reali riscontrati in produzione per aiutarvi a evitarli. Non si tratta di checklist teoriche. Sono errori che ho commesso realmente.
La trappola dell'autenticazione condizionale Ho scritto del codice che controllava se un segreto API esistesse prima di verificarlo. Se la variabile d'ambiente mancava, il controllo veniva saltato completamente. Ciò significava che l'intera mia API era aperta al pubblico. Regola: Se un segreto manca, fallisci drasticamente con un errore 500. Non saltare mai l'autenticazione.
La fuga dalla cronologia di Git Una volta ho inserito direttamente nel codice (hardcoded) una chiave API per un test rapido. Successivamente l'ho spostata in un file .env e pensavo che il problema fosse risolto. Ma Git ricorda tutto. Chiunque può trovare quella chiave nella mia cronologia dei commit. Regola: Se fai il commit di una chiave, dai per scontato che sia stata rubata. Ruotala immediatamente. Usa git-filter-repo per pulire la tua cronologia.
La fuga dell'endpoint di debug Ho lasciato un endpoint
/debug/configin produzione per aiutarmi a risolvere i problemi. Esponeva gli URL del mio database e le impostazioni dell'ambiente. Regola: Rimuovi tutti gli endpoint di debug prima del deployment. Usa i log al loro posto.Fuga di informazioni di sistema tramite errori Ho usato
str(e)nelle mie risposte di errore. Questo inviava errori del database e percorsi di file direttamente all'utente. Gli attaccanti usano questo metodo per mappare la tua infrastruttura. Regola: Registra l'errore dettagliato per te stesso. Invia un generico "Internal Server Error" al client.Il rischio XSS nel frontend Ho usato
innerHTMLper renderizzare i contenuti degli utenti. Questo permetteva l'esecuzione di script nei browser di altri utenti. Regola: Esegui sempre l'escape dell'HTML. ConsiderainnerHTMLcome un modo per eseguire codice arbitrario.Mancanza di Rate Limit Avevo endpoint che chiamavano modelli AI costosi senza alcun limite. Un singolo loop o una chiave rubata avrebbero potuto costarmi centinaia di dollari. Regola: L'autenticazione ferma gli utenti non autorizzati. Il rate limiting impedisce agli utenti autorizzati di abusare del tuo sistema.
Politica CORS permissiva Ho usato
allow_origins=["*"]in produzione. Questo permette a qualsiasi sito di inviare richieste alla tua API. Regola: Consenti solo il dominio specifico del tuo frontend.La perdita di file temporanei Se il mio codice andava in crash durante l'elaborazione di un file, il file temporaneo rimaneva sul disco per sempre. Questo spreca spazio e causa la fuga di dati sensibili. Regola: Usa i blocchi try-finally per garantire che i file vengano eliminati anche in caso di errore.
La mia nuova checklist obbligatoria:
Prima di scrivere il codice: • Crea un .gitignore • Crea un .env.example
Per ogni endpoint: • Aggiungi l'autenticazione • Usa messaggi di errore generici • Aggiungi dei rate limit ai task più onerosi
Prima di fare il commit: • Scansiona il diff alla ricerca di segreti
Prima del deployment: • Esegui audit di sicurezza sulle tue dipendenze
I problemi di sicurezza non accadono per caso. Accadono a causa di commenti "TODO" e correzioni "temporanee" che rimangono in produzione per sempre.
Riparare un bug è noioso. Riparare una violazione è costoso.