FAQ

Qual è il modo più efficace per prevenire la SQL injection?

Usa query parametrizzate, dette anche prepared statement, per ogni query che includa dati variabili. Una query parametrizzata invia al database separatamente la struttura SQL e i valori forniti dall'utente, così i valori non possono mai essere reinterpretati come codice SQL, chiudendo il vettore di injection alla radice. Gli ORM e i query builder che fanno binding dei parametri offrono la stessa garanzia, mentre la semplice concatenazione di stringhe - anche con escaping manuale - no, perché l'escaping è soggetto a errori e dipende dal contesto. Aggiungi account di database a privilegio minimo e validazione dell'input in allow-list come difesa in profondità, ma considera la parametrizzazione come il controllo primario non negoziabile.

Come fermo il cross-site scripting (XSS) in un'app web moderna?

Combina l'output encoding consapevole del contesto con una Content Security Policy rigorosa. L'encoding garantisce che i dati dell'utente siano resi come testo inerte in qualunque contesto appaiano (corpo HTML, attributo, JavaScript o URL), e framework moderni come React e Angular lo fanno automaticamente per i binding normali. Il pericolo è aggirare quei default tramite sink HTML grezzi come innerHTML o dangerouslySetInnerHTML; sanitizza tale input con una libreria affidabile se ti serve davvero HTML. Sovrapponi una CSP basata su nonce o hash così che anche uno script inline iniettato senza il nonce corretto venga bloccato dal browser.

È un compromesso tra esposizione all'XSS e superficie CSRF, e non esiste una risposta universalmente corretta. Tutto ciò che è in localStorage è leggibile da qualsiasi JavaScript in esecuzione sulla pagina, quindi una singola falla XSS può esfiltrare il token; un cookie HttpOnly è invisibile agli script ma viene inviato automaticamente, il che reintroduce il CSRF e richiede SameSite più token anti-CSRF. Per la maggior parte delle app browser, un cookie HttpOnly, Secure, SameSite che contiene un token a breve durata con un meccanismo di refresh lato server è il default più difendibile. Qualunque opzione scegli, mantieni i token a breve durata e assicurati di poterli revocare o ruotare.

Qual è la differenza tra autenticazione e autorizzazione?

L'autenticazione verifica chi è un principal, mentre l'autorizzazione decide cosa quel principal autenticato è abilitato a fare. Ti autentichi una volta per stabilire l'identità (password, passkey, token) e poi l'autorizzazione viene verificata a ogni operazione protetta rispetto alla nozione di identità e permessi del server. Confonderle è una causa comune di bug: un utente correttamente loggato può comunque eseguire azioni che non dovrebbe, ed è broken access control. Imponi sempre l'autorizzazione lato server per ogni richiesta, mai fidandoti di un ruolo fornito dal client o nascondendo opzioni nell'interfaccia.

Come prevengo gli attacchi CSRF?

Usa token anti-CSRF e imposta l'attributo SameSite sui cookie di sessione. Un token synchronizer o double-submit è un valore imprevedibile che il server emette e poi valida a ogni richiesta che modifica lo stato, dimostrando che la richiesta proviene dalle tue pagine anziché da una forgiata cross-site. SameSite=Lax o Strict istruisce inoltre il browser a non allegare il cookie di sessione sulle sottorichieste cross-site, bloccando la maggior parte del CSRF senza alcun token. Nota che il CSRF colpisce specificamente le sessioni basate su cookie; le API autenticate puramente con un bearer token in un header che il browser non allega automaticamente generalmente non vi sono esposte.

HTTPS è sufficiente per mettere in sicurezza il mio sito?

No. HTTPS (tramite TLS) protegge i dati in transito - riservatezza, integrità e autenticazione del server - ma non fa nulla contro le falle a livello applicativo come injection, broken access control, XSS o autenticazione debole. Un sito può essere completamente cifrato e comunque banalmente attaccabile. Considera il TLS come una baseline obbligatoria (con TLS 1.3, certificati validi e HSTS), poi affronta i rischi della OWASP Top 10 nell'applicazione stessa, oltre alla cifratura a riposo, alla gestione sicura delle sessioni e al privilegio minimo.

Cos'è la OWASP Top 10 e dovrei seguirla?

La OWASP Top 10 è una lista aggiornata regolarmente e guidata dalla comunità dei rischi di sicurezza più critici per le applicazioni web, usata in tutto il settore come baseline di consapevolezza e prioritizzazione. Non è uno standard esaustivo, ma cattura le categorie - broken access control, injection, fallimenti crittografici, configurazione errata di sicurezza e così via - che causano la maggior parte delle violazioni reali. Usala per ancorare un programma di sicurezza e la formazione degli sviluppatori, e passa al più granulare OWASP ASVS quando ti servono requisiti verificabili. Seguirla non ti certifica sicuro, ma ignorarla quasi garantisce buchi comuni ed evitabili.

Come dovrei conservare in modo sicuro le password degli utenti?

Non conservare mai le password in chiaro né con hashing veloce o reversibile. Usa una funzione di hashing per password lenta, con salt e memory-hard progettata allo scopo - Argon2id è la prima scelta attuale, con scrypt e bcrypt come alternative accettate - così che anche una violazione del database renda costoso il cracking offline. Il salt rende inutili gli attacchi con tabelle precalcolate (rainbow table) e deve essere unico per password; il work factor va calibrato il più alto possibile entro il tuo budget di latenza. Imponi una lunghezza minima ampia, filtra contro le password note come violate e offri l'MFA in aggiunta.

Cos'è l'SSRF e perché è pericoloso nel cloud?

La Server-Side Request Forgery (SSRF) inganna il server inducendolo a effettuare richieste verso una destinazione scelta dall'attaccante, particolarmente pericolosa negli ambienti cloud. Poiché la richiesta nasce all'interno del tuo confine di fiducia, può raggiungere servizi solo-interni e, criticamente, l'endpoint di metadati dell'istanza cloud all'indirizzo 169.254.169.254, che può fornire credenziali temporanee. Mitigala validando e mettendo in allow-list le destinazioni in uscita, bloccando i range IP link-local e privati, disabilitando schemi URL inutilizzati e il follow automatico dei redirect, e usando l'hardening del servizio di metadati come IMDSv2.

Cos'è il principio del privilegio minimo e come lo applico?

Privilegio minimo significa che a ogni utente, processo e service account vengono concessi solo i permessi strettamente richiesti per il suo compito e niente di più. In uno stack web lo applichi dando all'applicazione un utente di database limitato alle tabelle e alle operazioni che usa davvero, emettendo token API con scope ridotto e a breve durata, separando le credenziali di lettura e scrittura ed evitando di eseguire i servizi come root. Il beneficio è il contenimento: quando un singolo componente viene compromesso, l'attaccante eredita solo quel ristretto insieme di diritti, limitando nettamente il raggio d'impatto.

Mi serve ancora la validazione lato server se il frontend valida già l'input?

Sì, sempre. La validazione lato client è puramente una comodità di usabilità e performance e non offre alcuna sicurezza, perché un attaccante può aggirare del tutto il browser e inviare qualsiasi payload direttamente alla tua API con strumenti come curl. Ogni controllo rilevante per la sicurezza - validazione dell'input, autorizzazione, regole di business, rate limit - deve essere imposto sul server, l'unico luogo che controlli. Tratta tutti i dati in ingresso come non fidati a prescindere da quale client li abbia presumibilmente inviati.

Imposta gli attributi Secure, HttpOnly e SameSite sui cookie di sessione e considera il prefisso __Host-. Secure assicura che il cookie sia inviato solo su HTTPS, HttpOnly lo nasconde a JavaScript così che una falla XSS non possa leggerlo, e SameSite=Lax o Strict limita l'invio cross-site per ridurre il CSRF. Usa identificatori di sessione ad alta entropia, rigenera l'ID di sessione subito dopo il login per prevenire la fixation, applica timeout di inattività e assoluti e invalida la sessione lato server al logout.

Quali header di sicurezza dovrebbe inviare ogni app web?

Come minimo invia Content-Security-Policy (una policy rigorosa basata su nonce o hash), Strict-Transport-Security (HSTS per forzare HTTPS) e X-Content-Type-Options: nosniff (per fermare il MIME sniffing). Aggiungi Content-Security-Policy: frame-ancestors (o X-Frame-Options) per prevenire il clickjacking, e un Referrer-Policy sensato per limitare la fuga di referrer. Gli header sono difesa in profondità economica e ad alta leva, ma complementano - non sostituiscono mai - la scrittura di codice sicuro come output encoding e controllo accessi.

Come prevengo broken access control e IDOR?

Imponi un controllo di autorizzazione sul server per ogni accesso all'oggetto, verificando che l'utente autenticato possieda o sia abilitato ad agire sulla risorsa specifica - non semplicemente che sia loggato. Il classico fallimento IDOR/BOLA è esporre un identificatore (come /invoices/123) e servirlo senza controllare la proprietà, lasciando che gli attaccanti enumerino i dati altrui cambiando l'ID. Nega per default, centralizza la logica di autorizzazione così che sia difficile dimenticarla, usa riferimenti indiretti o non indovinabili dove utile e aggiungi test automatici che tentino l'accesso cross-tenant.

Qual è il modo più resistente al phishing per autenticare gli utenti?

WebAuthn / FIDO2 (passkey e chiavi di sicurezza) è il metodo più forte ampiamente disponibile perché l'autenticazione usa crittografia a chiave pubblica legata all'origine del sito, così la firma è inutile su un dominio di phishing simile e non c'è un segreto condiviso da rubare o rigiocare. A differenza delle password e persino dei codici TOTP, la chiave privata non lascia mai l'authenticator e non può essere sottratta via phishing. Dove le passkey non sono ancora praticabili, richiedi l'MFA e preferisci fattori push o codici usa-e-getta agli SMS, suscettibili di SIM-swapping.

Come gestisco il rischio di dipendenze di terze parti e di supply chain?

Tratta le tue dipendenze come parte della tua superficie d'attacco e controlla cosa entra nella tua build. Fissa le versioni con un lockfile committato, scansiona di continuo le dipendenze per vulnerabilità note, genera e mantieni un Software Bill of Materials (SBOM) e revisiona le aggiunte per typosquatting e cambi inattesi di manutenzione. Per gli script di terze parti caricati nel browser, aggiungi hash di Subresource Integrity così che un CDN compromesso non possa scambiare silenziosamente il file. Esegui la tua build e la CI a privilegio minimo così che un pacchetto malevolo non possa raggiungere i tuoi segreti.

Quando dovrei affidarmi a un Web Application Firewall (WAF)?

Usa un WAF come difesa in profondità e per il virtual patching rapido, ma mai come sostituto della correzione della falla sottostante. Un WAF blocca le richieste che corrispondono a pattern di attacco noti e può guadagnarti tempo dopo la divulgazione di una vulnerabilità, eppure gli attaccanti aggirano abitualmente il filtraggio basato su firme con codifiche nuove o logiche che non corrispondono a una regola. Tratta gli alert del WAF come segnale utile e come livello di allerta precoce, mentre correggi la vulnerabilità effettiva nel codice dell'applicazione.