Proteggere le Web App: 5 attacchi comuni e come evitarli

Nell'era della connettività ininterrotta, le web app rappresentano il cuore digitale di molte imprese e servizi. Si tratta però anche di bersagli ambiti per attacchi informatici che possono compromettere dati sensibili, reputazione aziendale e operatività. Spesso la differenza tra un'applicazione sicura e una vulnerabile sta nell'attenzione ai dettagli, nella conoscenza delle minacce e nell'implementazione di contromisure efficaci. In questo articolo ti guiderò attraverso i 5 attacchi più comuni alle web app e ti mostrerò come evitarli, anche con esempi pratici e snippet di codice.

Proteggere le Web App dal Cross‑Site Scripting (XSS)

L'XSS (Cross‑Site Scripting) consiste nell'iniezione di codice JavaScript malevolo nei contenuti di una pagina web. Se non gestito correttamente, può permettere agli aggressori di rubare cookie, token di autorizzazione o reindirizzare gli utenti verso siti dannosi.

Distinguiamo tre tipi di XSS:

• Stored XSS
• Reflected XSS
• DOM-Based XSS

Analizziamo quindi un code snippet basato su React + escape:

function SafeComment({ text }) {
  const sanitized = text.replace(//g, '>');
  return <div />;
}

Come difendersi? Ricorda di:

• Sanitizzare sempre gli input, ad esempio con DOMPurify
• Escapare gli output, specialmente quando generi HTML
• Content Security Policy (CSP): definisci quali script possono essere eseguiti e quali no.

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'none';

Proteggere le Web App dal Cross‑Site Request Forgery (CSRF)

Il CSRF sfrutta la sessione attiva dell'utente in un sito target: l'attaccante induce la vittima a compiere azioni (es. dei pagamenti) senza consenso, tramite richieste forzate nel browser. Ecco un esempio dove il caricamento dell'immagine esegue una richiesta GET indesiderata.

<img src="https://banca.example/trasferisci?destinatario=attacker&importo=1000">

Per difenderci possiamo sfruttare tre soluzioni:

• Token CSRF
• SameSite cookie attribute SameSite=Strict Lax
• Verifica origin/header POST

Il pericolo SQL Injection

L'SQL Injection sfrutta query dinamiche senza sanitizzazione, permettendo agli attaccanti di manipolare o leggere database protetti. Un esempio particolarmente pericoloso, basato su Node.js + MySQL, potrebbe essere il seguente

const query = `SELECT * FROM utenti WHERE email = '${req.body.email}'`;
db.query(query, callback);

Per quanto riguarda le difese, una prima soluzione sono le query parametrizzate e i prepared statement:

db.execute('SELECT * FROM utenti WHERE email = ?', [req.body.email]);

Abbiamo poi gli ORM con query protocollate (ad esempio con TypeORM) e la validazione schema dell'input, ad esempio con Ajv JSON schema validator.

Insecure Direct Object Reference (IDOR)

Si ha un IDOR quando un'API espone dei riferimenti diretti a risorse come https://api.example/user/123, permettendo a un utente autenticato di accedere a risorse non autorizzate come gli id di altri utenti:

app.get('/user/:id', authenticate, (req, res) => {
  const user = db.findUserById(req.params.id);
  res.json(user);
});

Nel nostro esempio un utente malintenzionato potrebbe inviare un /user/456 per accedere ad un altro account.

In questo caso l'autorizzazione temporale permette di verificare che il requester sia autorizzato.

if (req.user.id !== req.params.id) return res.status(403).send('Forbidden');

È poi consigliabile usare degli identificatori non scandibili (UUID) ed effettuare il controllo degli accessi a livello business logic, non solo dei percorsi URL.

Server‑Side Request Forgery (SSRF) e API Abuse

L'SSRF consente ad un aggressore di far sì che il server si backend effettui delle richieste HTTP arbitrarie, spesso verso risorse interne non esposte all'esterno. Ecco un esempio basato su Python, JavaScript e il cattivo uso di fetch:

const url = req.body.url;
const res2 = await fetch(url);
const text = await res2.text();
res.send(text);

Un attaccante potrebbe puntare verso http://169.254.169.254/latest/meta-data nel cloud AWS. Come difendersi?:

• Whitelisting dei domini consentiti.
• Sanitizzazione degli URL: impedire file:// http://localhost 10.0.0.0/8
• Timeout e limiti del client HTTP.
• Reti isolate: separare le richieste esterne da quelle interne.

Altri Accorgimenti per proteggere le Web App

Oltre ai cinque attacchi principali:

• Proteggi le sessioni HttpOnly same-site secure
• Rate limiting / Throttling
• Security headers Strict-Transport-Security
• Logging e monitoraggio
• Dependency scanning npm audit Snyk
• Penetration testing
• Formazione

Conclusione

Adottando queste pratiche e strumenti, ridurrai notevolmente i rischi legati agli attacchi più comuni e sarai in grado di costruire applicazioni più robuste, più affidabili e soprattutto più sicure. Ogni misura preventiva, ogni linea di codice scritta con consapevolezza, rappresenta un investimento concreto nella fiducia dei tuoi utenti e nella solidità del tuo progetto.

Troppo spesso la sicurezza viene vista come un elemento secondario, qualcosa da affrontare per ultima, magari dopo il rilascio o solo quando si presenta un problema. Ma la verità è che la sicurezza non è un'opzione, è una responsabilità. Non è un requisito da spuntare all'ultimo momento, ma una mentalità da abbracciare sin dalla progettazione. Ogni scelta tecnica, ogni componente utilizzato, ogni API esposta dovrebbe essere pensata con l'idea che potrebbe essere un potenziale vettore di attacco.

Pensare alla sicurezza fin dalla prima riga di codice significa anche adottare una cultura dello sviluppo orientata alla qualità. Vuol dire formare team consapevoli, effettuare code review attente, tenere aggiornate le dipendenze e testare con regolarità.

Inizia oggi, anche con piccoli passi. Ma inizia. Perché proteggere il tuo codice significa proteggere le persone che si fidano di esso.