Hai un firewall. Utilizzi HTTPS. Esegui “npm audit”. Ma se riesco a modificare il payload JSON di una richiesta di “acquisto” per inviare “prezzo: 0.01” e il tuo server lo accetta, il tuo firewall è inutile.

Il Penetration Testing (Pentesting) è la disciplina dell’ingegneria adversariale. Non si tratta di “selezionare le caselle” per la conformità. Si tratta di provare attivamente a distruggere la propria applicazione prima che lo faccia qualcun altro.

Noi di Maison Code Paris consideriamo la sicurezza come la forma definitiva di garanzia della qualità. Un bug che manda in crash l’app è fastidioso. Un bug che fa trapelare 10.000 carte di credito dei clienti è esistenziale.

Perché Maison Code ne parla

In Maison Code Paris, agiamo come la coscienza architettonica dei nostri clienti. Spesso ereditiamo stack “moderni” costruiti senza una comprensione fondamentale della scala.

Discutiamo di questo argomento perché rappresenta un punto di svolta critico nella maturità ingegneristica. Implementarlo correttamente differenzia un MVP fragile da una piattaforma resiliente di livello aziendale.

I limiti dell’automazione

La maggior parte dei team esegue uno scanner automatizzato (come OWASP ZAP o Nessus) e ritiene di essere sicuro. Gli scanner sono ottimi nel trovare errori di sintassi:

Iniezione SQL (' OR 1=1).
XSS (<script>avviso(1)</script>).
Librerie obsolete (CVE-2023-XXXX).

Gli scanner sono pessimi nel trovare Errori logici:

“Posso applicare lo stesso codice sconto 50 volte contemporaneamente?”
“Posso visualizzare la cronologia degli ordini dell’ID utente 5 se ho effettuato l’accesso come ID utente 4?”
“Posso impostare il prezzo dell’articolo su negativo?”

Queste sono Vulnerabilità della logica aziendale e rappresentano la maggior parte delle perdite finanziarie nel moderno e-commerce.

Vulnerabilità 1: IDOR (riferimento oggetto diretto non sicuro)

Questo è il difetto più comune nelle API moderne (GraphQL/REST). Succede quando ti fidi che il Cliente ti dica a quale risorsa accedere, senza verificarne la proprietà.

L’attacco: L’utente A accede. Guarda l’URL o la scheda Rete: “OTTIENI /api/orders/5001”. Lo cambiano in: “OTTIENI /api/orders/5002”.

Se il server restituisce l’ordine dell’utente B, hai un IDOR.

Il codice vulnerabile: “dattiloscritto”. // BAD: fidarsi dell’ID fornito dall’utente app.get(‘/api/orders/:id’, async (req, res) => { ordine const = attendono db.order.findUnique({ dove: { id: req.params.id } }); res.json(ordine); });


**Il codice di sicurezza**:
"dattiloscritto".
// BUONO: ambito della query per l'utente autenticato
app.get('/api/orders/:id', async (req, res) => {
  const sessione = attendono getSession(req);
  ordine const = attendono db.order.findFirst({
    dove: { 
      ID: req.params.id,
      userId: session.userId // Il controllo critico
    }
  });
  
  if (!ordine) restituisce res.status(404).send("Non trovato"); // Non dire "Proibito", dì semplicemente "Non trovato" per evitare perdite
  res.json(ordine);
});

Vulnerabilità 2: Condizioni di gara (Hack dei coupon)

I server Web sono simultanei. Gestiscono migliaia di richieste al secondo. Se la logica del tuo database non è “Thread Safe” (o Transaction Safe), sei vulnerabile.

L’attacco:

Il sito invia un codice promozionale: “SAVE50” (Limite di 1 utilizzo per cliente).
L’aggressore scrive uno script per inviare 50 richieste HTTP POST a /apply-coupon simultaneamente (entro 5 ms).
Il Server elabora la Richiesta 1: “L’utente ha utilizzato il coupon? No. Applica lo sconto.”
Il server elabora la richiesta 2 (prima che la richiesta 1 venga confermata nel DB): “L’utente ha utilizzato il coupon? No. Applica lo sconto.”
Risultato: l’utente riceve uno sconto di 50 volte. L’ordine è gratuito.

La soluzione: blocco del database: È necessario utilizzare le Transazioni con il Livello di isolamento corretto o il Blocco riga esplicito.

--PostgreSQL/MySQL
INIZIARE;
SELECT * FROM utenti WHERE id = 1 PER AGGIORNAMENTO; -- Blocca la riga
-- Controlla l'utilizzo del coupon
-- Applicare coupon
UPDATE utenti SET coupon_used = true WHERE id = 1;
IMPEGNO;

In termini Prisma/ORM, usa €transaction con isolamento interattivo se possibile, oppure usa un Mutex in Redis se hai a che fare con contatori distribuiti.

Vulnerabilità 3: attacchi alla catena di fornitura

Nel 2025 scrivi il 10% del tuo codice. Il restante 90% proviene da node_modules. Gli hacker hanno smesso di attaccare il tuo server; attaccano le tue dipendenze. Pubblicano un pacchetto come “lodash-utils” (typosquatting) o compromettono l’account di un popolare manutentore del pacchetto.

Difesa in profondità:

Lockfile: eseguire sempre il commit di package-lock.json. Garantisce versioni esatte.
Controlli CI: esegui npm audit --audit-level=high nella pipeline di compilazione. Interrompere la compilazione se vengono rilevati elementi critici.
Strumenti moderni: utilizzare Socket.dev o Snyk. Analizzano il comportamento del pacchetto (“Perché questa libreria CSS necessita dell’accesso alla rete?”).

Vulnerabilità 4: NoSQL Injection

Tutti conoscono SQL Injection. Ma se usi MongoDB, non sei immune. MongoDB consente oggetti di query. Se accetti JSON non elaborato dal client: db.users.find({ nome utente: req.body.username }).

L’attacco: L’utente invia JSON: { "username": { "€gt": "" } }. Questo si traduce in: “Trova gli utenti in cui il nome utente è maggiore della stringa vuota”. Questo corrisponde a tutti. L’aggressore accede come primo utente amministratore.

La soluzione: Sanificare gli ingressi. Non passare mai “req.body” direttamente a una query del database. Utilizza librerie come zod per convalidare la struttura (assicurati che username sia una stringa, non un oggetto).

“dattiloscritto”. importa { z } da ‘zod’;

const LoginSchema = z.oggetto({ nomeutente: z.string(), // Rifiuta oggetti come { €gt: "" } password: z.string() });

const corpo = LoginSchema.parse(req.body); // Genera un risultato se non valido


## L'esercizio della squadra rossa

A Maison Code, consigliamo un esercizio trimestrale **Red Team**.
Designiamo 2 ingegneri a cui *è consentito* attaccare l'ambiente di staging.
* Tentano di aggirare il pagamento.
* Tentano di aumentare i privilegi.
* Tentano di accedere ai dati di altri utenti.

Questa "gamificazione" della sicurezza crea una cultura in cui gli sviluppatori sono orgogliosi di trovare buchi, piuttosto che vergognarsi.

## 10. Programmi Bug Bounty (hacker come dipendenti)

Non è possibile assumere abbastanza ingegneri della sicurezza.
Ma puoi noleggiare gli hacker di tutto il mondo.
Aiutiamo i clienti a lanciarsi su **HackerOne** o **Bugcrowd**.
* **Politica**: "Se trovi un P1 (Critico), pagheremo $ 5.000."
* **Risultato**: Entro 24 ore, 500 ricercatori esamineranno il tuo sito.
*Troveranno* cose che il tuo scanner da $ 100.000 ha mancato.
"Ho trovato un modo per bypassare la 2FA rimuovendo il parametro `token`."
Pagare 5.000 dollari per tale scoperta è più economico di una multa da 5 milioni di dollari prevista dal GDPR.

## 11. Ingegneria sociale (il firewall umano)

Il tuo firewall è potente. Il tuo addetto alla reception è gentile.
Gli hacker lo sanno.
**Simulazione di phishing**: inviamo email false ai tuoi dipendenti.
"Urgente: il CEO ha bisogno di un bonifico bancario."
Se fanno clic, vengono iscritti alla formazione.
**Sicurezza fisica**: posso entrare nel vostro ufficio in modo efficace?
La sicurezza non è solo codice; sono le persone.

## 12. Gestione della postura di sicurezza nel cloud (CSPM)
        
Hai protetto il codice. Ma hai lasciato aperto il bucket S3?
Gli strumenti **CSPM** (Wiz, Orca) scansionano il tuo ambiente AWS.
"Avviso: la porta del database RDS 5432 è aperta a 0.0.0.0/0".
Questo non è un bug del codice. È un bug di configurazione.
Trattiamo Infrastructure as Code (Terraform) come un limite di sicurezza.
`chekov` viene eseguito nella nostra pipeline CI per bloccare qualsiasi commit che apra un gruppo di sicurezza al mondo.

## 13. Scansione segreta (il problema della storia di Git)

Hai commesso accidentalmente "AWS_SECRET_KEY" nel 2021.
L'hai eliminato nel prossimo commit.
**È ancora nella cronologia `.git`.**
Gli hacker clonano il tuo repository e guardano il registro.
Usiamo **TruffleHog** o **GitGuardian** per scansionare l'intera cronologia dei commit.
Se viene trovato un segreto, lo ruotiamo immediatamente. La revoca della chiave è l'*unica* soluzione.

## 14. Conclusione

La sicurezza non è un prodotto che si acquista. È una mentalità.
Se pensi "Sono troppo piccolo per essere hackerato", ti sbagli. I bot scansionano costantemente ogni indirizzo IP su Internet. A loro non importa se sei un Fortune 500 o un blog; se hai una vulnerabilità, la sfrutteranno per estrarre criptovalute o inviare spam.

Tratta la tua candidatura come una fortezza. Controlla ogni cancello. Non fidarti di nessuno.


<hr style="margin: 1rem 0" />
**[Assumi i nostri architetti](/contact)**.