Windsurf ha aiutato Linus a fare debug. Ma il tuo webhook potrebbe fidarsi di chiunque

Il debug accelera, ma la verifica resta il lavoro del founder

Linus Torvalds ha raccontato una sessione di debug particolarmente complessa, in cui un’AI ha svolto gran parte del lavoro ripetitivo: aggiungere codice diagnostico, analizzare risultati e continuare a investigare anche dopo aver dichiarato il problema quasi irrisolvibile. La notizia è Quoting Linus Torvalds, pubblicata il 22 agosto 2026.

Il dettaglio importante non è che l’AI abbia “risolto tutto da sola”. È che ha accelerato l’esplorazione, mentre la responsabilità di capire se la modifica fosse corretta è rimasta umana.

Questa distinzione vale anche per il tuo prodotto. Puoi usare un agente per costruire rapidamente un endpoint, collegare un servizio di pagamento o automatizzare una sincronizzazione. Il codice può compilare, i test possono passare e il flusso può sembrare pronto. Ma resta una domanda: chi può davvero chiamare quell’endpoint?

Cosa significa se il tuo codice l’ha scritto Windsurf

Immagina di aver usato Windsurf per aggiungere un webhook che riceve eventi da un provider esterno: pagamento completato, abbonamento rinnovato, documento aggiornato o ordine spedito.

Il flusso tipico è semplice:

1. il provider invia una richiesta HTTP;
2. il tuo endpoint legge il payload JSON;
3. il backend aggiorna il database;
4. l’app mostra il nuovo stato all’utente.

La versione generata dall’agente può funzionare perfettamente durante il test manuale. In locale invii un payload, il record cambia e la schermata si aggiorna.

Il buco nasce se il server accetta il payload senza verificare la firma digitale del provider. In quel caso chiunque conosca l’URL può inviare una richiesta costruita a mano e simulare un evento legittimo.

Il problema tecnico è uno solo: manca la validazione della firma del webhook prima di modificare lo stato applicativo.

Un attaccante potrebbe provare a segnare un pagamento come completato, riattivare un abbonamento, generare una spedizione o attivare una funzione riservata. La gravità dipende dal tipo di evento e dalle azioni collegate, ma il principio non cambia: il tuo backend sta trattando dati controllabili dall’esterno come se fossero già autenticati.

Non significa che Windsurf abbia scritto “codice cattivo”. Significa che un prompt come “aggiungi un webhook per aggiornare lo stato dell’ordine” può descrivere il comportamento funzionale senza esplicitare il requisito di autenticità, gestione dei replay e rifiuto delle richieste non firmate.

Perché ora ti serve un audit del repository

Qui l’audit non serve a rileggere ogni riga per sport. Serve a produrre un verdetto su una catena concreta: richiesta esterna, verifica, aggiornamento del database.

La domanda da risolvere è: ogni webhook che modifica dati verifica la firma sul payload originale, prima di eseguire qualsiasi effetto collaterale?

Per rispondere bisogna seguire il percorso completo:

• individuare gli endpoint webhook esposti dal repository;
• capire quale provider dovrebbe inviare ogni evento;
• verificare dove viene letta la chiave segreta o il certificato;
• controllare che la firma venga calcolata sul body grezzo, non su un JSON già riformattato;
• verificare che una firma assente, scaduta o non valida produca un rifiuto;
• controllare se il database viene aggiornato prima della validazione;
• cercare protezioni contro la ripetizione dello stesso evento.

Un audit VibeInspect analizza lo ZIP del repository e restituisce un PDF con score e verdetto. Nel piano Diagnostic, il report include file, righe ed evidenze: puoi vedere quale endpoint accetta l’evento, dove dovrebbe avvenire il controllo e quale operazione viene eseguita prima o dopo la verifica.

Il risultato che ti serve non è “sembra esserci una funzione per la firma”. È una conclusione operativa: PASS, oppure FAIL, con la catena di evidenze che ti permette di decidere se bloccare il rilascio, ruotare una chiave o correggere il flusso.

Questo è il passaggio che manca spesso nei repository costruiti velocemente. L’agente ha ottimizzato la produzione del codice. Nessuno ha ancora dimostrato che l’endpoint distingua davvero un provider autorizzato da una richiesta inventata.

L’evidenza deve collegare firma ed effetto collaterale

Un falso positivo è facile. Trovare una variabile chiamata WEBHOOK_SECRET non dimostra che il sistema sia protetto. La variabile potrebbe essere inutilizzata, caricata nel posto sbagliato o confrontata dopo l’aggiornamento del database.

Allo stesso modo, una funzione chiamata verifySignature non basta. Bisogna capire se viene chiamata da tutti gli endpoint rilevanti e se riceve esattamente il contenuto che il provider ha firmato.

Un report utile deve distinguere almeno tre casi:

1. la firma è verificata prima dell’elaborazione e le richieste non valide vengono rifiutate;
2. la verifica esiste, ma alcuni endpoint o percorsi alternativi la aggirano;
3. il payload viene accettato e lo stato viene modificato senza autenticazione crittografica.

Conta anche la gestione dei replay. Una firma valida dimostra che il provider ha firmato un messaggio, ma non sempre impedisce di riutilizzare lo stesso messaggio più volte. Se l’evento attiva un’azione non idempotente, il repository dovrebbe avere un modo per riconoscere l’ID dell’evento già elaborato.

L’audit non deve inventare un attacco. Deve mostrare se il codice contiene o meno i controlli necessari per sostenere il comportamento dichiarato.

Cosa un linter non vede

Un linter controlla regole locali: sintassi, tipi, import, formattazione e alcuni pattern conosciuti. Non sa necessariamente che un endpoint dovrebbe ricevere richieste solo da Stripe, GitHub, Shopify o da un altro provider.

Non ricostruisce sempre il rapporto tra header, body grezzo, chiave segreta e aggiornamento del database. Non sa se una firma viene controllata prima di emettere un rimborso, attivare un account o cambiare il piano di un cliente.

Anche i test possono dare un falso senso di sicurezza. Se il test invia una richiesta con un payload valido e controlla soltanto che il risultato sia 200, dimostra la funzionalità ma non la protezione. Serve anche verificare che una firma mancante o alterata venga rifiutata e che nessun effetto collaterale avvenga prima del rifiuto.

Il linter ti dice che il codice rispetta certe regole. L’audit ti dice se il confine tra evento attendibile e input arbitrario è applicato lungo il percorso reale.

Cosa fare questa settimana

1. Elenca tutti gli endpoint che ricevono webhook o callback esterne.
2. Per ciascuno, identifica il provider atteso e il meccanismo di firma previsto.
3. Verifica che il controllo usi il body grezzo ricevuto dalla richiesta.
4. Assicurati che firma assente o non valida interrompa il flusso prima del database.
5. Controlla timestamp, finestra di validità e protezione contro replay.
6. Rendi idempotente l’elaborazione usando l’identificatore univoco dell’evento.
7. Aggiungi test negativi: firma mancante, payload alterato, timestamp scaduto e evento duplicato.
8. Se hai usato Windsurf per creare il flusso e non sai formulare un verdetto, esegui un audit Diagnostic prima del prossimo rilascio.

Non devi smettere di usare Windsurf. Devi smettere di confondere un endpoint funzionante con un endpoint autenticato. La velocità dell’AI è utile quando riduce il lavoro ripetitivo; diventa un rischio quando il repository arriva in produzione senza una prova chiara di ciò che accetta e di ciò che rifiuta.

Carica lo ZIP del repository e ottieni un verdetto con evidenze tecniche: avvia un audit Diagnostic.