Ciao! Sono

Federico Calò

Sviluppatore Software | Divulgatore Tecnico

Creo applicazioni web moderne e strumenti digitali personalizzati per aiutare le attività a crescere attraverso l'innovazione tecnologica. La mia passione è unire informatica ed economia per generare valore reale.

Contattami

Chi Sono

La mia passione per l'informatica è nata tra i banchi dell'Istituto Tecnico Commerciale di Maglie, dove ho scoperto il potere della programmazione e il fascino di creare soluzioni digitali. Fin da subito, ho capito che l'informatica non era solo codice, ma uno strumento straordinario per trasformare idee in realtà.

Durante gli studi superiori in Sistemi Informativi Aziendali, ho iniziato a intrecciare informatica ed economia, comprendendo come la tecnologia possa essere il motore della crescita per qualsiasi attività. Questa visione mi ha accompagnato all'Università degli Studi di Bari, dove ho conseguito la Laurea in Informatica, approfondendo le mie competenze tecniche e la mia passione per lo sviluppo software.

Oggi metto questa esperienza al servizio di imprese, professionisti e startup, creando soluzioni digitali su misura che automatizzano processi, ottimizzano risorse e aprono nuove opportunità di business. Perché la vera innovazione inizia quando la tecnologia incontra le esigenze reali delle persone.

Le Mie Competenze

Analisi Dati & Modelli Previsionali

Trasformo i dati in insights strategici con analisi approfondite e modelli predittivi per decisioni informate

Automazione Processi

Creo strumenti personalizzati che automatizzano operazioni ripetitive e liberano tempo per attività a valore aggiunto

Sistemi Custom

Sviluppo sistemi software su misura, dalle integrazioni tra piattaforme alle dashboard personalizzate

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

La Mia Missione

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

Democratizzare la Tecnologia

La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.

Unire Informatica ed Economia

Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.

Creare Soluzioni su Misura

Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.

Trasforma la Tua Attività con la Tecnologia

Che tu gestisca un negozio, uno studio professionale o un'azienda, posso aiutarti a sfruttare le potenzialità dell'informatica per lavorare meglio, più velocemente e in modo più intelligente.

Parliamone Insieme →

Unisciti alla Community

Entra nella community di sviluppatori dove discutiamo di software, AI, architettura e DevOps. Condividi idee, fai domande e cresci insieme a noi.

Canale

FC Dev Blog

Ricevi notifiche su nuovi articoli, serie complete, tips settimanali e tool in evidenza. Contenuti bilingui IT/EN direttamente nel tuo Telegram.

Nuovi articoli appena pubblicati
Tips e code snippets settimanali
Sondaggi sugli argomenti futuri

Iscriviti al Canale

Gruppo

FC Dev Community

Una community bilingue IT/EN per sviluppatori. Discussioni, Q&A, aiuto reciproco e networking con altri professionisti del settore.

Discussioni su articoli e tecnologie
Help coding e code review
Opportunità di lavoro e collaborazione

Unisciti al Gruppo

Topic di Discussione

Visualizza

Master SQL

RoadMap.sh

Novembre 2024

Visualizza

Oracle Certified Foundations Associate

Oracle

Ottobre 2024

Visualizza

People Leadership Credential

Connect

Settembre 2024

Linguaggi & Tecnologie

Java

Python

JavaScript

Angular

React

TypeScript

SQL

PHP

CSS/SCSS

Node.js

Docker

Git

💼

12/2024 - Presente

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italia · Ibrida Analisi e sviluppo di sistemi informatici attraverso l'utilizzo di Java e Quarkus in Health and Public Sector. Formazione continua su tecnologie moderne per la creazione di soluzioni software personalizzate ed efficienti e sugli agenti.

💼

06/2022 - 12/2024

Analista software e Back End Developer Associate Consultant

Links Management and Technology SpA

Esperienza nell'analisi di sistemi software as-is e flussi ETL utilizzando PowerCenter. Formazione completata su Spring Boot per lo sviluppo di applicazioni backend moderne e scalabili. Sviluppatore Backend specializzato in Spring Boot, con esperienza in progettazione di database, analisi, sviluppo e testing dei task assegnati.

💼

02/2021 - 10/2021

Programmatore software

Adesso.it (prima era WebScience srl)

Esperienza nell'analisi AS-IS e TO-BE, evoluzioni SEO ed evoluzioni website per migliorare le performance e l'engagement degli utenti.

🎓

2018 - 2025

Laurea in Informatica

Università degli Studi di Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Sistemi Informativi Aziendali

Istituto Tecnico Commerciale di Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

Contattami

Hai un progetto in mente? Parliamone! Compila il form qui sotto e ti risponderò al più presto.

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

01 - OWASP Top 10 2025: Guida per Developer

Ogni riga di codice che scriviamo porta con se una responsabilità implicita: proteggere i dati e la fiducia degli utenti. Nel 2025, con applicazioni sempre più complesse, architetture distribuite e la crescente adozione di strumenti di generazione automatica del codice, la sicurezza non può più essere un ripensamento. La OWASP Top 10 2025 rappresenta il riferimento aggiornato delle dieci vulnerabilità più critiche nelle applicazioni web, e ogni developer dovrebbe conoscerla a fondo.

Questa guida analizza tutte le dieci categorie della nuova lista, con un focus particolare sulle due nuove categorie introdotte nel 2025: Software Supply Chain Failures (A03) e Mishandling of Exceptional Conditions (A10). Per ogni vulnerabilità troverai spiegazioni chiare, codice vulnerabile e sicuro in TypeScript/Node.js, e best practice specifiche per Angular.

Cosa Imparerai

Tutte le 10 categorie OWASP 2025, incluse le 2 nuove
Le differenze principali rispetto alla versione 2021
Esempi di codice vulnerabile e le relative contromisure
Come proteggere la supply chain delle dipendenze npm
perchè il 45% del codice AI-generated fallisce i test di sicurezza
Una checklist Angular-specific per mettere in sicurezza le tue applicazioni

Cos'è OWASP e Come Nasce il Top 10

La Open Worldwide Application Security Project (OWASP) e una fondazione no-profit nata nel 2001 con l'obiettivo di migliorare la sicurezza del software a livello globale. Il suo progetto più noto e la OWASP Top 10: un documento di riferimento che elenca le dieci vulnerabilità più critiche nelle applicazioni web, aggiornato periodicamente sulla base di dati reali raccolti da centinaia di organizzazioni.

La lista viene compilata analizzando milioni di applicazioni e centinaia di migliaia di vulnerabilità. Il processo combina dati empirici (incidenti reali, report di sicurezza, analisi automatizzate) con un sondaggio della comunita che raccoglie le preoccupazioni degli esperti di sicurezza sulle minacce emergenti. Ogni categoria mappa uno o più CWE (Common Weakness Enumeration), ovvero classificazioni standard delle debolezze software.

Le Versioni Precedenti

La OWASP Top 10 ha avuto diverse edizioni: 2004, 2007, 2010, 2013, 2017, 2021 e ora 2025. Ogni aggiornamento riflette l'evoluzione delle minacce. Nel 2017 le Injection erano al primo posto; nel 2021 il Broken Access Control le ha superate. Nel 2025 assistiamo a cambiamenti ancora più significativi, con l'ingresso di due categorie completamente nuove che riflettono le sfide moderne dello sviluppo software.

Le Novità della OWASP Top 10 2025

L'edizione 2025 porta cambiamenti importanti rispetto al 2021. Ecco la lista completa con le variazioni di posizione:

Posizione	OWASP 2025	Cambiamento da 2021
A01	Broken Access Control	Confermato al #1 (era A01:2021). Include ora SSRF
A02	Security Misconfiguration	Sale da #5 a #2
A03	Software Supply Chain Failures	NUOVA - espande A06:2021 (Vulnerable Components)
A04	Cryptographic Failures	Scende da #2 a #4
A05	Injection	Scende da #3 a #5
A06	Insecure Design	Scende da #4 a #6
A07	Authentication Failures	Confermato a #7
A08	Software or Data Integrity Failures	Confermato a #8
A09	Security Logging and Alerting Failures	Confermato a #9 (rinominato: "Alerting" al posto di "Monitoring")
A10	Mishandling of Exceptional Conditions	NUOVA - sostituisce SSRF (ora inglobato in A01)

I Due Cambiamenti Chiave

A03: Software Supply Chain Failures - Gli attacchi alla supply chain del software sono esplosi negli ultimi anni. Questa categoria e stata votata come la preoccupazione principale nel sondaggio della comunita OWASP. Copre typosquatting, dependency confusion, pacchetti malevoli e compromissione delle pipeline CI/CD.

A10: Mishandling of Exceptional Conditions - La gestione errata degli errori e delle eccezioni e ora riconosciuta come vettore di attacco autonomo. Include 24 CWE relative a error handling inadeguato, fail-open, e leak di informazioni sensibili tramite messaggi di errore.

A01:2025 - Broken Access Control

Il Broken Access Control resta saldamente al primo posto per il quarto anno consecutivo. Si verifica quando un utente riesce ad accedere a risorse o eseguire azioni per cui non ha l'autorizzazione. Le forme più comuni includono: IDOR (Insecure Direct Object Reference), path traversal, bypass dei controlli di ruolo, e manipolazione di token o parametri URL.

Nel 2025, questa categoria ha inglobato il SSRF (Server-Side Request Forgery), che nella versione 2021 occupava la posizione A10. La logica e che il SSRF rappresenta fondamentalmente un fallimento nel controllo degli accessi: il server esegue richieste verso risorse che non dovrebbe raggiungere.

Esempio: IDOR (Insecure Direct Object Reference)

API vulnerabile vs sicura - Accesso ai dati utente

// VULNERABILE: nessun controllo di ownership
app.get('/api/users/:id/profile', async (req, res) => {
  // Chiunque può vedere il profilo di qualsiasi utente cambiando l'ID
  const user = await User.findById(req.params.id);
  res.json(user);
});

// SICURO: verifica ownership + ruolo
app.get('/api/users/:id/profile', authenticate, async (req, res) => {
  if (req.user.id !== req.params.id && req.user.role !== 'admin') {
    return res.status(403).json({ error: 'Accesso non autorizzato' });
  }
  const user = await User.findById(req.params.id);
  if (!user) {
    return res.status(404).json({ error: 'Utente non trovato' });
  }
  res.json(user);
});

Esempio: Path Traversal

Prevenzione del path traversal nei file download

import path from 'path';

// VULNERABILE: l'utente controlla il percorso del file
app.get('/api/files/:filename', (req, res) => {
  // Un attaccante può richiedere: ../../../etc/passwd
  res.sendFile(`/uploads/#123;req.params.filename}`);
});

// SICURO: normalizza e valida il percorso
const UPLOAD_DIR = '/var/www/uploads';

app.get('/api/files/:filename', authenticate, (req, res) => {
  const filename = path.basename(req.params.filename);
  const filePath = path.join(UPLOAD_DIR, filename);

  // Verifica che il percorso risolto sia dentro UPLOAD_DIR
  if (!filePath.startsWith(UPLOAD_DIR)) {
    return res.status(400).json({ error: 'Percorso non valido' });
  }

  res.sendFile(filePath);
});

      Difese Angular per il Broken Access Control
      Implementa Route Guards (canActivate, canMatch) per proteggere le rotte riservate
Usa un HTTP Interceptor per allegare automaticamente il token JWT ad ogni richiesta
Nascondi gli elementi UI in base ai permessi, ma valida sempre lato server
Non inserire mai ruoli o permessi nel localStorage senza verifica lato backend
Centralizza la logica di autorizzazione in un AuthService riutilizzabile

    

A02:2025 - Security Misconfiguration

Le Security Misconfiguration salgono dalla posizione #5 alla #2 nel 2025. Questo balzo riflette un dato reale: con la crescente complessità delle configurazioni (cloud, container, microservizi, CDN), gli errori di configurazione sono diventati una delle cause più frequenti di breach.

Questa categoria include: configurazioni di default non modificate, header HTTP di sicurezza mancanti, CORS troppo permissivi, stack trace esposti in produzione, porte e servizi non necessari esposti, e feature di debug lasciate attive.

Header di Sicurezza e CORS

Configurazione sicura di header HTTP e CORS

import helmet from 'helmet';
import cors from 'cors';

const app = express();

// Header di sicurezza con Helmet
app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'"],
      styleSrc: ["'self'", "https://fonts.googleapis.com"],
      imgSrc: ["'self'", "data:", "https:"],
      fontSrc: ["'self'", "https://fonts.gstatic.com"],
      connectSrc: ["'self'", "https://api.tuodominio.com"],
      frameAncestors: ["'none'"],  // Protegge da clickjacking
      objectSrc: ["'none'"],
    }
  },
  referrerPolicy: { policy: 'strict-origin-when-cross-origin' },
  hsts: { maxAge: 31536000, includeSubDomains: true, preload: true },
}));

// CORS restrittivo
app.use(cors({
  origin: ['https://tuodominio.com'],
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true,
  maxAge: 86400 // Cache preflight per 24 ore
}));

Errori di Configurazione Comuni

Access-Control-Allow-Origin: * in produzione
Stack trace completi visibili nelle risposte di errore
Credenziali di default non modificate (admin/admin)
Porte di debug (9229 per Node.js) esposte in produzione
File .env accessibili pubblicamente
Directory listing abilitato sul web server

A03:2025 - Software Supply Chain Failures (NUOVA)

Questa e una delle novità più importanti della OWASP Top 10 2025. La categoria Software Supply Chain Failures espande la precedente A06:2021 (Vulnerable and Outdated Components) per coprire un ambito molto più ampio: non solo le dipendenze vulnerabili, ma l'intero ecosistema di build, distribuzione e aggiornamento del software.

Nel 2025 questa categoria ha registrato il tasso di incidenza medio più alto (5,19%) tra tutte le categorie quando testata. E stata anche votata come la preoccupazione principale nel sondaggio della comunita OWASP, segnalando che gli esperti di sicurezza considerano gli attacchi alla supply chain come la minaccia in più rapida crescita.

Tipologie di Attacco alla Supply Chain

Gli attacchi alla supply chain del software si manifestano in diverse forme, ciascuna con caratteristiche e livelli di sofisticazione diversi:

Typosquatting: pacchetti malevoli con nomi simili a librerie popolari (es. lodahs invece di lodash, expres invece di express)
Dependency Confusion: un pacchetto pubblico con lo stesso nome di uno interno viene installato al posto di quello legittimo
Account Takeover: compromissione degli account dei maintainer per iniettare codice malevolo in pacchetti legittimi
Build Pipeline Poisoning: iniezione di codice malevolo nella pipeline CI/CD durante il processo di build
Slopsquatting: pacchetti che sfruttano nomi di dipendenze inventati dalle AI (allucinazioni) come target di attacco

Incidente Reale: Settembre 2025

A settembre 2025, una campagna di phishing ha compromesso account di maintainer npm, risultando nella compromissione di almeno 27 pacchetti con miliardi di download settimanali. Un worm auto-replicante chiamato Shai-Hulud ha infettato oltre 500 pacchetti prima di essere neutralizzato. Questo incidente dimostra quanto sia critica la protezione della supply chain.

Difese Pratiche per la Supply Chain

Protezione delle dipendenze npm

# 1. Usa npm ci (non npm install) per rispettare il lockfile
npm ci

# 2. Audit delle vulnerabilità in CI/CD
npm audit --audit-level=high

# 3. Verifica le firme dei pacchetti (npm 9+)
npm audit signatures

# 4. Blocca i registry non autorizzati in .npmrc
registry=https://registry.npmjs.org/
@mycompany:registry=https://npm.mycompany.com/

# 5. Genera e verifica SBOM (Software Bill of Materials)
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

Protezione avanzata con lockfile e pinning

// package.json - usa versioni esatte, non range
{
  "dependencies": {
    "express": "4.21.2",
    "helmet": "8.0.0",
    "cors": "2.8.5"
  },
  "overrides": {
    "vulnerable-transitive-dep": "2.1.0"
  }
}

      Checklist Supply Chain per Progetti Angular
      Esegui npm audit in ogni pipeline CI/CD con soglia di blocco
Usa Dependabot o Renovate per aggiornamenti automatici
Attiva la 2FA su tutti gli account npm dei maintainer
Verifica l'origine dei pacchetti prima di installarli (npm info)
Genera un SBOM per ogni release e monitoralo con strumenti dedicati
Usa npm ci (non npm install) in tutti gli ambienti automatizzati
Configura una allowlist di registry autorizzati in .npmrc

    

A04-A07: Panoramica delle Categorie Confermate

A04:2025 - Cryptographic Failures

Scende da #2 a #4 ma resta una vulnerabilità critica. Riguarda la protezione inadeguata dei dati sensibili: password salvate in chiaro o con hash deboli (MD5, SHA1), chiavi crittografiche hardcoded nel codice sorgente, trasmissione di dati senza HTTPS, e algoritmi di cifratura obsoleti.

Hash password: vulnerabile vs sicuro

import bcrypt from 'bcrypt';
import crypto from 'crypto';

// VULNERABILE: MD5 non e sicuro per le password
const insecureHash = crypto.createHash('md5').update(password).digest('hex');

// SICURO: bcrypt con salt rounds adeguato
const SALT_ROUNDS = 12;
const secureHash = await bcrypt.hash(password, SALT_ROUNDS);

// SICURO: verifica password senza timing attack
const isValid = await bcrypt.compare(inputPassword, storedHash);

A05:2025 - Injection

Le Injection scendono da #3 a #5, segno che le contromisure (ORM, query parametrizzate, sanitizer) si sono diffuse. Tuttavia restano pericolose. Include SQL Injection, NoSQL Injection, Command Injection, LDAP Injection e XSS.

SQL Injection: la difesa più importante

// VULNERABILE: concatenazione diretta
const query = `SELECT * FROM users WHERE email = '#123;userInput}'`;
// Input malevolo: ' OR '1'='1' --

// SICURO: query parametrizzate (PostgreSQL)
const result = await pool.query(
  'SELECT * FROM users WHERE email = $1',
  [userInput]
);

// SICURO: ORM con sanitizzazione automatica (TypeORM)
const user = await userRepository.findOneBy({
  email: userInput  // TypeORM sanitizza automaticamente
});

A06:2025 - Insecure Design

Riguarda difetti nella progettazione dell'applicazione, non nell'implementazione. L'assenza di threat modeling, il mancato rispetto del principio del minimo privilegio, e l'omissione di controlli come il rate limiting sono tutti esempi di insecure design. La differenza chiave: un design sicuro può avere bug di implementazione, ma un design insicuro non può essere corretto solo con codice migliore.

A07:2025 - Authentication Failures

I fallimenti nell'autenticazione includono: accettazione di password deboli, sessioni che non scadono, token JWT senza scadenza o con segreti deboli, e assenza di Multi-Factor Authentication. La difesa principale e implementare JWT con scadenza breve, refresh token sicuri, e validazione rigorosa delle credenziali.

A08-A09: Integrita e Monitoraggio

A08:2025 - Software or Data Integrity Failures

Questa categoria si concentra sul mantenimento della fiducia e della verifica dell'integrita del software, del codice e degli artefatti a un livello più granulare rispetto alla Supply Chain (A03). Include: pipeline CI/CD senza verifica di integrita, auto-update senza validazione delle firme, deserializzazione di dati non attendibili, e assenza di Subresource Integrity (SRI) per risorse esterne.

Subresource Integrity per risorse CDN

<!-- VULNERABILE: script esterno senza verifica -->
<script src="https://cdn.example.com/lib.js"></script>

<!-- SICURO: SRI verifica l'integrita del file -->
<script
  src="https://cdn.example.com/lib.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
  crossorigin="anonymous">
</script>

A09:2025 - Security Logging and Alerting Failures

Rinominata nel 2025 con l'aggiunta di "Alerting" al posto di "Monitoring" per enfatizzare l'importanza non solo di registrare gli eventi, ma di generare alert attivi quando si verificano anomalie. Senza logging strutturato e alerting, un breach può restare non rilevato per mesi.

Logging strutturato per eventi di sicurezza

import winston from 'winston';

const securityLogger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.json()
  ),
  defaultMeta: { service: 'auth-service' },
  transports: [
    new winston.transports.File({ filename: 'security.log' }),
  ]
});

// Eventi CRITICI da loggare e per cui generare alert
function logFailedLogin(email: string, ip: string): void {
  securityLogger.warn({
    event: 'FAILED_LOGIN',
    email,
    ip,
    timestamp: new Date().toISOString(),
    alert: true  // Flag per il sistema di alerting
  });
}

// REGOLA: 5 login falliti dallo stesso IP = alert immediato
// REGOLA: accesso admin da IP sconosciuto = alert immediato
// REGOLA: modifica permessi fuori orario = alert immediato

      Cosa Loggare (e cosa NON loggare)
      Logga: login riusciti/falliti, accessi negati (403), modifiche a dati sensibili, azioni admin
NON loggare: password, token, numeri di carta di credito, dati personali completi
Genera alert per: pattern anomali di login, accessi da geolocalizzazioni inusuali, picchi di errori 4xx/5xx

    

A10:2025 - Mishandling of Exceptional Conditions (NUOVA)

La seconda grande novità del 2025. Questa categoria contiene 24 CWE relative alla gestione impropria di errori, eccezioni e condizioni anomale. Il concetto chiave e il "fail-open": quando un'applicazione, di fronte a un errore, sceglie di concedere l'accesso o continuare l'operazione invece di bloccarla.

Le condizioni eccezionali possono derivare da: input mancante o incompleto, stati ambientali imprevisti (memoria, rete, permessi), gestione tardiva degli errori a livelli alti invece che dove si verificano, e eccezioni non gestite affatto.

CWE Chiave in Questa Categoria

CWE-209: Messaggi di errore che contengono informazioni sensibili
CWE-234: Mancata gestione di parametri mancanti
CWE-274: Gestione impropria di privilegi insufficienti
CWE-476: Dereferenziazione di puntatore null
CWE-636: "Failing Open" - non fallire in modo sicuro

Esempio: Fail-Open nell'Autenticazione

Error handling che crea vulnerabilità

// VULNERABILE: fail-open - in caso di errore l'utente passa
async function verifyToken(req: Request, res: Response, next: NextFunction) {
  try {
    const token = req.headers.authorization?.split(' ')[1];
    const decoded = jwt.verify(token!, process.env.JWT_SECRET!);
    req.user = decoded;
    next();
  } catch (error) {
    // ERRORE CRITICO: in caso di eccezione, si prosegue comunque!
    console.log('Token verification failed, continuing...');
    next(); // L'utente non autenticato accede alle risorse protette
  }
}

// SICURO: fail-closed - in caso di errore l'accesso e negato
async function verifyToken(req: Request, res: Response, next: NextFunction) {
  try {
    const token = req.headers.authorization?.split(' ')[1];
    if (!token) {
      return res.status(401).json({ error: 'Token mancante' });
    }
    const decoded = jwt.verify(token, process.env.JWT_SECRET!);
    req.user = decoded;
    next();
  } catch (error) {
    // CORRETTO: in caso di errore, si blocca l'accesso
    return res.status(401).json({ error: 'Autenticazione fallita' });
  }
}

Esempio: Information Leakage tramite Errori

Messaggi di errore che rivelano informazioni sensibili

// VULNERABILE: espone dettagli interni del sistema
app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
  res.status(500).json({
    error: err.message,
    stack: err.stack,           // Rivela percorsi del file system
    query: (err as any).sql,    // Rivela struttura del database
    config: (err as any).config // Potrebbe rivelare credenziali
  });
});

// SICURO: messaggi generici in produzione, dettagli solo in sviluppo
const isProduction = process.env.NODE_ENV === 'production';

app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
  // Logga i dettagli internamente
  securityLogger.error({
    message: err.message,
    stack: err.stack,
    url: req.originalUrl,
    method: req.method,
    ip: req.ip
  });

  // Restituisci solo un messaggio generico al client
  res.status(500).json({
    error: isProduction
      ? 'Si e verificato un errore. Riprova più tardi.'
      : err.message
  });
});

Esempio: Resource Exhaustion da Gestione Errata

Leak di risorse quando le eccezioni non vengono gestite correttamente

// VULNERABILE: il file handle non viene rilasciato in caso di errore
async function processUpload(filePath: string): Promise<void> {
  const handle = await fs.open(filePath, 'r');
  const data = await handle.readFile(); // Se fallisce, il handle resta aperto
  await processData(data);
  await handle.close();
}

// SICURO: pattern try/finally per garantire il rilascio delle risorse
async function processUpload(filePath: string): Promise<void> {
  let handle: fs.FileHandle | null = null;
  try {
    handle = await fs.open(filePath, 'r');
    const data = await handle.readFile();
    await processData(data);
  } catch (error) {
    securityLogger.error({ event: 'UPLOAD_FAILED', filePath, error });
    throw new AppError('Elaborazione file fallita', 500);
  } finally {
    if (handle) {
      await handle.close(); // Sempre eseguito, anche in caso di errore
    }
  }
}

Principio Fondamentale: Fail-Closed

Ogni volta che un'eccezione si verifica in un contesto di sicurezza, il sistema deve negare l'accesso per default (fail-closed), mai concederlo (fail-open). Questo vale per autenticazione, autorizzazione, validazione input e qualsiasi decisione che influenza la sicurezza.

Focus: La Sicurezza del Codice Generato dall'AI

Con l'adozione massiccia di strumenti di AI coding (Copilot, ChatGPT, Claude, Cursor), un nuovo rischio emerge: la sicurezza del codice generato automaticamente. Secondo il GenAI Code Security Report 2025 di Veracode, che ha analizzato il codice prodotto da oltre 100 LLM su 80 task reali, i risultati sono preoccupanti.

I Numeri della Sicurezza AI

45% dei campioni di codice AI-generated fallisce i test di sicurezza e introduce vulnerabilità OWASP Top 10
72% di failure rate per il codice Java generato da AI
38-45% di failure rate per Python, C# e JavaScript
86% di failure rate specifico per Cross-Site Scripting (CWE-80)
88% di failure rate specifico per Log Injection (CWE-117)

Il Problema Non Migliora

I modelli AI fanno scelte sbagliate quasi la meta delle volte riguardo la sicurezza, e questo non sta migliorando con modelli più grandi. Il problema e sistemico: i modelli sono addestrati su codice pubblico che spesso contiene le stesse vulnerabilità che dovrebbero evitare. Il codice AI-generated richiede sempre una revisione di sicurezza umana.

Checklist di Sicurezza per Codice AI-Generated

Non accettare mai codice AI-generated senza code review di sicurezza
Verifica che le query al database siano parametrizzate (no concatenazione)
Controlla che l'input utente sia validato e sanitizzato in ogni punto
Assicurati che i secret non siano hardcoded nel codice generato
Verifica la gestione degli errori: deve essere fail-closed, non fail-open
Controlla i permessi e l'autorizzazione: l'AI spesso genera codice senza controlli di accesso
Esegui SAST (Static Application Security Testing) automatizzato su tutto il codice AI-generated

Checklist Sicurezza Angular-Specific

Angular offre numerose protezioni di sicurezza integrate, ma e fondamentale conoscerle e non disabilitarle inavvertitamente. Ecco una checklist specifica per applicazioni Angular:

Protezione XSS Integrata

DomSanitizer: quando usarlo e quando no

import { DomSanitizer, SafeHtml } from '@angular/platform-browser';

// Angular sanitizza automaticamente il binding nel template
// Le doppie graffe eseguono l'escape dell'HTML automaticamente

// PERICOLOSO: bypassare il sanitizer
@Component({
  template: `<div [innerHTML]="trustedHtml"></div>`
})
export class UnsafeComponent {
  trustedHtml: SafeHtml;

  constructor(private sanitizer: DomSanitizer) {
    // SOLO se il contenuto e completamente fidato e sotto il tuo controllo
    this.trustedHtml = this.sanitizer.bypassSecurityTrustHtml(content);
  }
}

// SICURO: lasciare che Angular sanitizzi automaticamente
@Component({
  template: `<div [textContent]="userContent"></div>`
})
export class SafeComponent {
  userContent = ''; // Angular esegue l'escape automaticamente
}

HttpClient e Interceptor di Sicurezza

Interceptor per autenticazione e gestione errori

import { HttpInterceptorFn, HttpErrorResponse } from '@angular/common/http';
import { inject } from '@angular/core';
import { Router } from '@angular/router';
import { catchError, throwError } from 'rxjs';

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const router = inject(Router);
  const token = getStoredToken(); // Da un servizio sicuro

  // Aggiungi il token solo alle richieste verso la tua API
  const secureReq = req.url.startsWith('/api')
    ? req.clone({
        setHeaders: { Authorization: `Bearer #123;token}` }
      })
    : req;

  return next(secureReq).pipe(
    catchError((error: HttpErrorResponse) => {
      if (error.status === 401) {
        // Token scaduto o invalido: redirect al login
        router.navigate(['/login']);
      }
      // Non esporre dettagli dell'errore nell'interfaccia
      return throwError(() => new Error('Richiesta fallita'));
    })
  );
};

Route Guard con Functional API

Protezione delle rotte con guard funzionali (Angular 16+)

import { CanActivateFn, Router } from '@angular/router';
import { inject } from '@angular/core';

export const authGuard: CanActivateFn = (route, state) => {
  const authService = inject(AuthService);
  const router = inject(Router);

  if (!authService.isAuthenticated()) {
    // Redirect al login con URL di ritorno
    router.navigate(['/login'], {
      queryParams: { returnUrl: state.url }
    });
    return false;
  }

  // Verifica ruolo se richiesto dalla rotta
  const requiredRole = route.data?.['role'];
  if (requiredRole && !authService.hasRole(requiredRole)) {
    router.navigate(['/unauthorized']);
    return false;
  }

  return true;
};

Content Security Policy per Angular

CSP header per applicazioni Angular

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-RANDOM_VALUE';
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https:;
  connect-src 'self' https://api.tuodominio.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';

      Checklist Finale Angular
      Non usare bypassSecurityTrustHtml con contenuto utente
Usa HttpClient con interceptor per token e gestione errori centralizzata
Implementa Route Guards funzionali per tutte le rotte protette
Configura una CSP restrittiva nel server che serve l'applicazione Angular
Non memorizzare token JWT in localStorage: preferisci cookie HttpOnly
Valida sempre lato server: i guard Angular proteggono solo la UI, non l'API
Usa il flag --subresource-integrity in ng build per generare hash SRI
Mantieni Angular aggiornato: ogni versione include patch di sicurezza

    

Conclusioni e Piano d'Azione

La OWASP Top 10 2025 riflette un panorama delle minacce in rapida evoluzione. Le due nuove categorie, Supply Chain Failures e Mishandling of Exceptional Conditions, non sono aggiunte accademiche: rappresentano minacce concrete che colpiscono applicazioni reali ogni giorno. La salita di Security Misconfiguration al secondo posto conferma che la complessità delle infrastrutture moderne crea superfici di attacco sempre più ampie.

Piano d'Azione per Developer

Ecco un percorso pratico in tre fasi per migliorare la postura di sicurezza delle tue applicazioni:

Settimana 1 - Fondamentali: Implementa controlli di accesso su tutte le API (A01), configura header di sicurezza con Helmet (A02), e attiva npm audit nella pipeline CI/CD (A03)
Settimana 2 - Protezione Dati: Migra a bcrypt/argon2 per le password (A04), verifica che tutte le query siano parametrizzate (A05), e implementa rate limiting (A06)
Settimana 3 - Monitoraggio: Configura logging strutturato con alerting (A09), rivedi tutti i blocchi catch per eliminare fail-open (A10), e genera un SBOM delle dipendenze (A03)

Prossimi Articoli della Serie

Nei prossimi articoli approfondiremo singole aree della sicurezza web con guide pratiche e codice completo:

Articolo 02: XSS e CSRF - Attacchi Cross-Site e come prevenirli in Angular
Articolo 03: SQL Injection e NoSQL Injection - Deep dive con Node.js e MongoDB
Articolo 04: Autenticazione Sicura - JWT, OAuth2, e sessioni

La sicurezza delle applicazioni web non e un checkpoint da superare una volta sola: e un processo continuo che deve essere integrato in ogni fase dello sviluppo, dal design alla produzione. Come developer, abbiamo la responsabilità di scrivere codice sicuro di default. Le vulnerabilità OWASP Top 10 rappresentano il minimo indispensabile da conoscere. Il costo di prevenire una vulnerabilità e sempre inferiore al costo di subirne le conseguenze.