Sicurezza Web per Sviluppatori: La Guida Pillar Definitiva (OWASP, HTTPS, Laravel, Audit)

Hai mai ricevuto una telefonata da un cliente che ti dice «il sito non funziona» e scopri che è stato hackerato? Noi di Meteora Web sì, più volte. Un form di contatto lasciato senza protezione, una dependency dimenticata, un certificato SSL scaduto. Il risultato? Giornate perse a bonificare, clienti scontenti e — a volte — dati esposti.

Questa guida non è un elenco di ricette astratte. È il condensato di anni di riparazioni, audit e costruzioni fatte in produzione. Parleremo di OWASP, SQL injection, XSS, CSRF, HTTPS, autenticazione, audit delle dipendenze, rate limiting e penetration testing. Ogni sezione finisce con qualcosa che puoi applicare subito.

Partiamo da un presupposto: un sito insicuro è un costo, non un asset. E costa molto di più ripararlo che prevenirlo.

Il vero costo di una falla di sicurezza

Quando gestisci i bilanci dei clienti, come facciamo noi da ex contabili, capisci che una vulnerabilità non è solo un bug: è un rischio economico. Settimane di sviluppo perse, danni reputazionali, sanzioni GDPR. Noi lo vediamo ogni giorno nelle PMI italiane: la sicurezza è sistematicamente sottovalutata.

Esempio concreto: un nostro cliente, un e-commerce moda, aveva un form di login senza rate limiting. In una notte, un bot ha provato 50.000 password. Fortunatamente avevamo hash bcrypt e account bloccato dopo 5 tentativi. Se non fosse stato così, il costo sarebbe stato enorme.

La lezione? Investire in sicurezza non è un costo, è un assicurazione sul fatturato.

OWASP Top 10 2025 — la mappa delle vulnerabilità più pericolose

OWASP Top 10 è la lista delle vulnerabilità web più critiche, aggiornata periodicamente. Nel 2025 la classifica vede ancora al primo posto i Broken Access Control, seguiti da Cryptographic Failures e Injection. Ogni sviluppatore dovrebbe conoscerla come il manuale di un framework.

Noi la usiamo come checklist in ogni nuovo progetto: all'avvio, controlliamo autenticazione, autorizzazioni, validazione input e crittografia. Se salti questo passaggio, stai costruendo su sabbia.

Come applicarla in pratica

Scarica la guida OWASP, stampala e mettila sulla scrivania. Per ogni endpoint della tua applicazione, chiediti: «questo può essere abusato?». Se la risposta è «non lo so», devi approfondire.

SQL Injection — prevenzione in PHP Laravel e MySQL

La SQL injection è l'attacco più vecchio e ancora tra i più frequenti. Un utente malintenzionato inserisce comandi SQL in un input e ottiene l'accesso al database. In Laravel, Eloquent ORM e Query Builder usano prepared statements, che neutralizzano automaticamente le injection. Ma attenzione: se usi raw SQL, sei esposto.

// ✅ Sicuro: Eloquent usa prepared statements
$user = User::where('email', $request->input('email'))->first();

// ❌ Pericoloso: concatenazione diretta
$user = DB::select("SELECT * FROM users WHERE email = '" . $request->input('email') . "'");

Regola d'oro: non concatenare mai input dell'utente in query SQL. Usa sempre ORM, Query Builder o prepared statements nativi. Se devi fare query complesse, scrivile con DB::raw() ma solo su dati controllati.

Strumenti utili: il middleware ValidateInput personalizzato per sanificare i campi, e l'analisi statica con phpstan per individuare possibili vulnerabilità nel codice.

XSS — Cross-Site Scripting: stored, reflected, DOM

Lo XSS permette a un attaccante di iniettare script JavaScript in una pagina vista da altri utenti. Può rubare cookie, token, o reindirizzare a siti malevoli. In Laravel, il sistema di template Blade scappa automaticamente l'output con {{ $var }}, ma se usi {!! $var !!} sei responsabile della sanificazione.

// ✅ Sicuro: Blade scappa l'output
<p>{{ $userInput }}</p>

// ⚠️ Da usare solo se hai già sanificato con htmlspecialchars
<p>{!! htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8') !!}</p>

CSP (Content Security Policy) è il tuo secondo strato di difesa. Vediamo come configurarlo negli header.

CSRF — proteggere form e API con token

Il Cross-Site Request Forgery sfrutta la sessione attiva di un utente per compiere azioni non autorizzate. Laravel ha un middleware CSRF integrato che verifica un token in ogni richiesta POST/PUT/DELETE. È attivo di default nei form Blade se usi @csrf.

<form method="POST" action="/update-profile">
    @csrf
    <input type="text" name="name">
    <button type="submit">Aggiorna</button>
</form>

Per le API stateless (ad esempio con Sanctum o Passport), il CSRF non serve perché usi token bearer. Ma attenzione alle CORS: configura solo origini fidate.

Security Headers — CSP, HSTS, X-Frame-Options

Gli header HTTP sono un firewall invisibile. Impostarli correttamente riduce drasticamente la superficie d'attacco. Ecco una configurazione di base per nginx:

add_header Content-Security-Policy "default-src 'self'; script-src 'self';";
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header Referrer-Policy "strict-origin-when-cross-origin";

Da testare subito: usa Security Headers per controllare il tuo sito. Noi lo facciamo su ogni deploy.

HTTPS e TLS — Let's Encrypt e configurazione nginx

Ormai non ci sono scuse: con Let's Encrypt i certificati SSL sono gratuiti e l'automazione con Certbot è semplice. Eppure ancora vediamo siti con certificati scaduti o TLS 1.0 attivo.

sudo certbot --nginx -d esempio.com -d www.esempio.com

Dopo aver ottenuto il certificato, disabilita protocolli obsoleti e configura una cipher suite forte:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;

Importante: abilita HSTS dopo aver verificato che tutto funzioni, altrimenti blocchi gli utenti in caso di problemi.

Autenticazione sicura — bcrypt, Argon2, sessioni

L'hashing delle password è un pilastro. Usa sempre bcrypt o Argon2. In Laravel, il comando Hash::make() usa bcrypt di default. Mai MD5, mai SHA1 senza sale. Noi abbiamo visto database con password in chiaro. È una ferita aperta.

// Registrazione
$user = User::create([
    'password' => Hash::make($request->password),
]);

// Login
if (Hash::check($request->password, $user->password)) {
    // password corretta
}

Gestione sessioni: rigenera l'ID sessione dopo il login ($request->session()->regenerate()). Imposta un timeout di inattività e usa cookie HttpOnly, Secure e SameSite.

Dipendenze sicure — npm audit, composer audit, CVE monitoring

Un pacchetto vulnerabile può far crollare l'intero castello. Ogni settimana escono nuove CVE. Noi abbiamo un workflow automatico: a ogni push, la CI esegue npm audit e composer audit. Se ci sono vulnerabilità critiche, il deploy si blocca.

# Controlla le dipendenze PHP
composer audit

# Controlla le dipendenze Node
npm audit

# Aggiorna tutto
composer update
npm update

Consiglio: usa strumenti come Dependabot (GitHub) o Renovate per ricevere PR automatiche di aggiornamento. Non rimandare mai un fix di sicurezza.

Rate limiting e protezione brute force — implementazione pratica

Il rate limiting è la tua barriera contro attacchi di forza bruta e DDoS. In Laravel, puoi usare il middleware throttle già integrato:

// In routes/api.php
Route::middleware('throttle:60,1')->group(function () {
    // 60 richieste al minuto
});

// Per login: 5 tentativi al minuto
Route::post('/login', [AuthController::class, 'login'])->middleware('throttle:5,1');

Nota: combina il rate limiting con il blocco dell'account dopo N tentativi falliti. E logga tutto per l'audit.

Penetration testing base per sviluppatori

Non serve essere hacker professionisti per eseguire un test di sicurezza di base. Ecco gli strumenti che usiamo noi in Meteora Web:

• OWASP ZAP: proxy di intercettazione e scanner automatico.
• Burp Suite Community: per manipolare richieste HTTP.
• Nikto: scanner di vulnerabilità web server.
• WPScan: specifico per WordPress.

Esegui una scansione almeno una volta al mese. Pianifica i fix in base alla criticità: le vulnerabilità critiche devono essere risolte entro 24 ore, le medie entro una settimana.

In sintesi — cosa fare adesso

1. Controlla gli header di sicurezza del tuo sito con securityheaders.com. Configura CSP, HSTS, X-Frame-Options.
2. Rinnova i certificati SSL (o automatizzali con Certbot). Disabilita TLS 1.0/1.1.
3. Esegui audit delle dipendenze: composer audit e npm audit. Aggiorna subito i pacchetti con vulnerabilità note.
4. Verifica che tutti i form abbiano CSRF token e che l'output sia sanitizzato (Blade {{ }}).
5. Implementa rate limiting su login, registrazione e API pubbliche.

Se hai bisogno di una mano, noi di Meteora Web lavoriamo ogni giorno su questi temi. Dalla consulenza alla remediation, passando per audit completi. Perché un sito sicuro non è un optional: è la base per fare business.