Sicurezza dal Giorno 1: Gli Errori OWASP Più Comuni nelle Startup (e Come Evitarli)
"Siamo troppo piccoli per essere attaccati" è la convinzione più pericolosa che possa avere un founder di startup. Le startup vengono attaccate proprio perché sono piccole: meno risorse dedicate alla sicurezza, più vulnerabilità, più facili da sfruttare. Un attaccante non ha bisogno di un motivo personale — un bot automatico scansiona migliaia di applicazioni al giorno cercando le vulnerabilità più basilari.
E le trova. Nelle startup che hanno dato priorità alla velocità rispetto alla sicurezza (comprensibile), che hanno rimandato la sicurezza "a quando cresceremo" (pericoloso), o che semplicemente non hanno mai considerato che qualcuno potesse fare SQL injection sul loro endpoint di login (ingenuo).
La buona notizia: la maggior parte delle vulnerabilità che colpiscono le startup sono note, documentate e prevenibili. L'OWASP le cataloga ogni anno, e le più comuni non richiedono un team di sicurezza dedicato per essere prevenute — richiedono ingegneri che le conoscano e ne tengano conto quando scrivono codice.
L'OWASP Top 10 che interessa alla tua startup
L'OWASP pubblica regolarmente la sua Top 10 delle vulnerabilità web. Non le passerò tutte in rassegna — mi concentrerò sulle cinque che riscontro più frequentemente nelle startup.
1. Broken Access Control (OWASP #1)
È la vulnerabilità numero uno per un motivo: è incredibilmente comune e devastante. Significa che un utente può accedere a dati o funzioni a cui non dovrebbe.
Esempi reali che ho visto:
- Cambiare l'ID nell'URL (
/api/users/123/orders) per vedere gli ordini di un altro utente. - Un utente con ruolo "viewer" che riesce a fare richieste POST perché il backend verifica i permessi solo nel frontend.
- Endpoint admin accessibili senza autenticazione perché "nessuno conosce l'URL".
Come evitarlo:
- Verifica l'autorizzazione su ogni endpoint del backend. Non fidarti mai del frontend per il controllo degli accessi. Il frontend è un suggerimento visivo; il backend è la legge.
- Implementa RBAC (Role-Based Access Control) fin dall'inizio. Non "quando avremo più ruoli". Fin dall'inizio.
- Nega di default. Ogni endpoint dovrebbe richiedere autenticazione e autorizzazione esplicita. Se dimentichi di proteggere un endpoint, che fallisca in modo sicuro, non in modo aperto.
- Testa l'autorizzazione. Scrivi test che tentino di accedere a risorse con l'utente sbagliato. Se quei test non esistono, quelle vulnerabilità probabilmente sì.
2. Injection (OWASP #3)
La SQL injection esiste da più di 20 anni, e continua a presentarsi. Anche NoSQL injection, command injection e LDAP injection. Il pattern è sempre lo stesso: input dell'utente che viene interpretato come codice.
-- Se costruisci le query così, sei esposto:
SELECT * FROM users WHERE email = '" + userInput + "'
-- Un attaccante invia: ' OR '1'='1
-- E accede a tutti gli utenti.
Come evitarlo:
- Query parametrizzate sempre. Senza eccezioni. Ogni ORM moderno (Prisma, SQLAlchemy, Sequelize, TypeORM) le usa di default. Se stai scrivendo SQL raw con concatenazione di stringhe, fermati.
- Validazione dell'input. Tutto ciò che arriva dall'utente è sospetto. Valida tipi, lunghezze, formati. Non solo nel frontend — anche nel backend.
- Principio del minimo privilegio nel database. La tua applicazione non dovrebbe connettersi al database con un utente che può fare DROP TABLE. Crea utenti con permessi limitati a ciò di cui l'applicazione ha bisogno.
3. Insecure Design (OWASP #4)
Questa è più sottile e più difficile da correggere a posteriori. Non è un bug di implementazione — è un difetto di progettazione. La sicurezza è stata pensata come un afterthought, non come parte del design.
Esempi:
- Un sistema di reset password che invia la nuova password via email in testo semplice.
- Un'API che restituisce tutti i campi dell'utente (incluso l'hash della password) perché "il frontend già filtra quello che mostra".
- Un flusso di checkout che si fida del prezzo inviato dal client invece di calcolarlo sul server.
Come evitarlo:
- Threat modeling durante la progettazione. Prima di scrivere codice, chiediti: "come potrebbe qualcuno abusare di questo?". Non serve un framework formale — una conversazione di 15 minuti alla lavagna è meglio di niente.
- Non fidarti mai del client. Tutto ciò che arriva dal frontend è un input, non una fonte di verità. Prezzi, permessi, identità — tutto si valida e calcola sul server.
- Principio della minima esposizione. La tua API dovrebbe restituire esattamente i dati necessari, non l'intero oggetto del database. Usa DTO o serializer che controllino quali campi vengono esposti.
4. Security Misconfiguration (OWASP #5)
La configurazione insicura è il risultato della fretta. Non è che qualcuno abbia deciso di essere insicuro — è che nessuno ha controllato i default.
I problemi più frequenti:
- Credenziali di default su database, pannelli admin o servizi.
- Bucket S3 pubblici con dati degli utenti. Succede ancora nel 2024.
- Messaggi di errore verbosi in produzione che rivelano stack trace, versioni del software o struttura del database.
- CORS configurato come
*in produzione perché "così funziona" durante lo sviluppo. - Header di sicurezza mancanti: senza HSTS, senza Content-Security-Policy, senza X-Frame-Options.
Come evitarlo:
- Checklist di sicurezza prima di ogni deploy. Non deve essere lunga. Dieci punti che si controllano sistematicamente.
- Ambienti di sviluppo e produzione con configurazioni diverse. I messaggi di errore dettagliati sono utili in dev. In produzione, restituisci un errore generico e logga i dettagli internamente.
- Audita regolarmente i tuoi servizi cloud. Strumenti come AWS Trusted Advisor, ScoutSuite o Prowler scansionano la tua infrastruttura cercando misconfigurazioni.
5. Vulnerable and Outdated Components (OWASP #6)
La tua applicazione ha decine (o centinaia) di dipendenze. Ognuna è una superficie di attacco potenziale. Una dipendenza non aggiornata con un CVE noto è una porta aperta con un cartello che dice "entra pure".
Ricordi Log4Shell? Una vulnerabilità in una libreria di logging Java che ha colpito mezzo internet. La tua startup probabilmente usa decine di librerie con un livello di scrutinio simile.
Come evitarlo:
- Dependabot o Renovate per aggiornamenti automatici delle dipendenze. Configuralo dal primo giorno. Non costa nulla e previene i problemi più ovvi.
- Snyk o npm audit nella tua pipeline CI. Che la build fallisca se c'è una vulnerabilità critica nota. Sì, a volte è scomodo. Meno scomodo di una violazione dei dati.
- Controlla cosa installi. Prima di fare
npm install pacchetto-random, guarda quanti download ha, quando è stato aggiornato l'ultima volta, chi lo mantiene. Le librerie abbandonate sono bombe a orologeria.
Quick win: sicurezza di base per qualsiasi startup
Non serve essere un esperto di sicurezza per implementare questo. Sono cose che ogni team di ingegneria dovrebbe fare di default:
- HTTPS ovunque. Senza eccezioni. Let's Encrypt è gratuito. Non ci sono scuse per HTTP nel 2024.
- Hashing delle password con bcrypt o Argon2. Se stai usando MD5 o SHA256 senza salt per le password, fermati adesso.
- Rate limiting sugli endpoint di autenticazione. Login, registrazione, reset password. Senza rate limiting, un bot può provare migliaia di password al minuto.
- CORS configurato correttamente. Solo le origini necessarie, non
*. - Secret nelle variabili d'ambiente. Mai nel codice, mai nel repo. Se la tua API key di Stripe è in un file
.envcommittato, sei già compromesso. - Aggiornamenti delle dipendenze regolari. Settimanalmente o come minimo mensilmente.
- Log di accesso e autenticazione. Devi sapere chi ha tentato di accedere a cosa e quando. È la base per la risposta agli incidenti.
Checklist pre-lancio
Prima che la tua applicazione incontri un utente reale, verifica:
- Tutti gli endpoint richiedono autenticazione (tranne quelli che esplicitamente non devono)
- L'autorizzazione viene verificata nel backend, non solo nel frontend
- Non ci sono credenziali hardcodate nel codice
- Gli errori in produzione non espongono informazioni interne
- HTTPS è forzato in tutti gli ambienti
- Le dipendenze non hanno CVE critici noti
- Il rate limiting è attivo sugli endpoint sensibili
- I backup sono configurati e testati (sì, testati — un backup che non si riesce a ripristinare non è un backup)
- I log di autenticazione sono attivi
Non è esaustivo, ma copre i fondamentali che la maggior parte delle startup ignora.
La sicurezza come abitudine ingegneristica
La sicurezza non si implementa in uno sprint prima dell'audit. Si costruisce come abitudine, in ogni pull request, in ogni decisione di design. Gli ingegneri senior che integrano la sicurezza nel loro processo di sviluppo non sono più lenti — sono più efficienti, perché non generano debito di sicurezza che qualcuno dovrà pagare dopo.
In Conectia, gli ingegneri che integriamo nel tuo team trattano la sicurezza come parte dello sviluppo, non come una checklist esterna. Costruiscono con l'OWASP in mente fin dal primo commit, configurano pipeline con scansione delle dipendenze, e progettano API che falliscono in modo sicuro. Perché un incidente di sicurezza in una startup in fase iniziale può costare molto più che denaro — può costare la fiducia dei tuoi primi utenti.
Il tuo team di ingegneria ha la sicurezza integrata nel processo di sviluppo? Parla con un CTO — integriamo ingegneri senior che costruiscono in modo sicuro di default, non come afterthought.
