Come fare un audit di sicurezza gratuito del tuo sito fatto con l'IA, passo per passo

Hai creato un sito o un'app web con ChatGPT? Scopri come verificare la presenza di vulnerabilità comuni usando strumenti gratuiti, prima di metterlo online.

Se hai seguito la mia analisi sui rischi nascosti del vibe coding e la checklist delle 7 falle più comuni nel codice generato dall’IA, conosci già la regola pratica: ChatGPT, Claude e Cursor possono scrivere codice che funziona subito, ma non equivalgono a «sicuro di default».

Quando chiedi a un modello linguistico di realizzare una web app o una pagina dinamica, l’obiettivo tipico del prompt è un’applicazione funzionante nel minor tempo possibile. Il risultato può essere un codice con poche difese perimetrali — pronto da pubblicare, ma esposto alle scansioni automatiche dei bot se non lo rivedi.

La buona notizia è che non serve essere penetration tester certificati per intercettare molte delle scorciatoie e delle falle grossolane più comuni (nei miei test). In questa guida pratica passo per passo, ti mostro come eseguire un audit di sicurezza gratuito sul tuo sito o sulla tua applicazione web prima del rilascio pubblico, sfruttando una combinazione di verifiche manuali e strumenti online gratuiti e autorevoli.

ℹ️ Nota / Prerequisito operativo
Per eseguire questo audit ti servono due elementi:

1. Il codice sorgente del tuo progetto (accessibile sul tuo computer per il controllo dei file locali).
2. L’indirizzo pubblico del sito (il dominio o l’URL di un ambiente di staging/test online su cui hai distribuito l’app).

---

Passaggio 1 — La caccia ai segreti nel codice sorgente (Controllo manuale)

Prima ancora di caricare il codice sul server o renderlo pubblico, verifica che non ci siano credenziali riservate nei file — un pattern che l’IA può lasciare se il prompt non chiede variabili d’ambiente.

1. Apri la cartella del tuo progetto nel tuo editor di sviluppo (come VS Code) o usa la ricerca globale nei file (Ctrl + Shift + F su Windows, Cmd + Shift + F su Mac).
2. Cerca in modo sistematico le seguenti parole chiave:
   • api_key
   • password
   • secret
   • token
   • db_pass
   • private_key
3. Se trovi righe come DATABASE_URL = "postgres://user:12345@host:5432/db" o STRIPE_KEY = "sk_live_...", fermati immediatamente.

# Esempio di file .env separato (da NON condividere mai)
DATABASE_PASSWORD="TuaPasswordForteSegreta"
TELEGRAM_BOT_TOKEN="123456789:ABCDEF..."
API_SECRET_KEY="chiave-privata-non-pubblicata"

Come risolvere con l’IA:
Apri la chat del tuo assistente e chiedi:
“Riscrivi il mio progetto in modo che tutte le chiavi API, token e password siano lette esclusivamente da variabili d’ambiente tramite file .env. Genera anche un file .env.example con valori fittizi e un file .gitignore che escluda il file .env dal repository.”

---

Passaggio 2 — Controllare gli “Scudi” del Server con Mozilla Observatory

Quando un visitatore accede al tuo sito, il server invia al browser speciali istruzioni chiamate Security Headers (Intestazioni HTTP di sicurezza). Questi header proteggono i visitatori da attacchi di dirottamento dei clic (Clickjacking), iniezioni di script dannosi (XSS) e downgrade di connessione.

Nei boilerplate generati senza richieste esplicite, l’IA può omettere questi header nei file di server (Express, Flask/FastAPI, Nginx/Apache). Non è una legge del modello: è un risultato tipico quando il prompt chiede solo «falla funzionare».

Per testare gratuitamente la robustezza degli header del tuo sito:

1. Visita lo strumento ufficiale e gratuito observatory.mozilla.org.
2. Inserisci il dominio del tuo sito (es. tuosito.com) e clicca su Scan Me.
3. Attendi pochi secondi per visualizzare il report e il voto globale (da A+ a F).

I tre header fondamentali da controllare nel report sono:

• Content-Security-Policy (CSP): Definisce da quali sorgenti esterne il browser può scaricare immagini, font e script.
• Strict-Transport-Security (HSTS): Obbliga il browser a comunicare esclusivamente tramite connessioni cifrate HTTPS.
• X-Frame-Options: Impedisce che il tuo sito venga incorporato all’interno di iframe malevoli su siti terzi.

Come risolvere con l’IA:
Copia l’elenco degli header contrassegnati in rosso nel report di Mozilla e chiedi a ChatGPT/Claude:
“Il mio sito web ospitato su [inserisci il tuo web server, es. Nginx / Apache / Express / Cloudflare] non ha i seguenti security headers: Content-Security-Policy, Strict-Transport-Security e X-Frame-Options. Forniscimi le direttive di configurazione esatte per abilitarli con una policy sicura e restrittiva.”

---

Passaggio 3 — Il test empirico del “Cattivo Utente” (XSS e SQL Injection)

Se la tua applicazione web accetta input da parte dei visitatori (un modulo contatti, una barra di ricerca, una sezione commenti o un campo login), devi verificare come il codice gestisce dati insoliti o non conformi.

Test 1: Cross-Site Scripting (XSS)

Vai su ogni campo di testo del tuo sito e inserisci questa stringa esatta:

<script>alert("Test Sicurezza")</script>

• Esito sicuro: Il testo viene stampato a schermo come stringa letterale (<script>...), oppure il modulo restituisce un messaggio di errore impedendo l’invio.
• Esito insicuro: Compare una finestra di pop-up nel browser con la scritta “Test Sicurezza”. Se compare il pop-up, l’applicazione non sta filtrando (sanitizzando) i caratteri HTML, consentendo a chiunque di iniettare codice JavaScript ed eseguire furti di cookie di sessione.

🚨 Avviso critico — Moduli e Database (SQL Injection)
Se il tuo modulo salva i dati in un database relazionale (SQLite, MySQL, PostgreSQL), prova a inserire un singolo apice ' o una combinazione come ' OR '1'='1 nel campo di ricerca o username. Se l’applicazione va in crash mostrando un errore di database (Syntax error near...), il codice è vulnerabile a SQL Injection.

Come risolvere con l’IA:
Chiedi al modello linguistico:
“Verifica tutti gli endpoint del mio server che ricevono dati dall’utente. Assicurati che l’HTML in ingresso venga sempre sanificato (usando librerie come DOMPurify o escape nativo) e che tutte le query al database siano parametrizzate al 100% con prepared statements.”

---

Passaggio 4 — Verifica della crittografia con Qualys SSL Labs

Avere il certificato HTTPS attivo non è sufficiente; occorre verificare che la configurazione del protocollo TLS non utilizzi standard obsoleti (come SSLv3 o TLS 1.0) soggetti a intercettazioni.

1. Vai su ssllabs.com/ssltest.
2. Inserisci il dominio del tuo sito.
3. Seleziona la casella “Do not show the results on the boards” per non rendere pubblico il test.
4. Avvia la verifica (richiede 1-2 minuti).

Secondo la mia esperienza diretta:

• Grado A / A+: Configurazione ottimale. Il server supporta TLS 1.2 e TLS 1.3 con cifrari robusti.
• Grado B o inferiore: Spesso indica che il provider di hosting mantiene attivi protocolli obsoleti o certificati intermedi mancanti. In tal caso, contatta il supporto del tuo hosting o attiva il proxy di sicurezza Cloudflare per elevare la valutazione ad A+.

---

Sintesi operativa: Cosa testare e con quali strumenti

La seguente matrice riepiloga i passaggi dell’audit gratuito pre-lancio:

---

Domande Frequenti (FAQ)

Questo audit gratuito è sufficiente per un e-commerce o per un sito che raccoglie dati sanitari?

No. Questa procedura è pensata per siti vetrina, blog, piccole automazioni e prototipi personali sviluppati con il vibe coding. Siti web che elaborano transazioni con carte di credito (conformità PCI-DSS) o dati sanitari richiedono valutazioni di conformità formali, penetration test professionali e analisi con scanner di vulnerabilità a pagamento.

Posso scansionare il mio sito web con Mozilla Observatory mentre è ancora su localhost?

No, strumenti online come Mozilla Observatory o SSL Labs hanno bisogno di raggiungere il tuo server tramite un dominio pubblico con indirizzo IP visibile su internet. Se vuoi testare un’applicazione locale prima della pubblicazione, puoi esporla temporaneamente usando tunnel cifrati come ngrok o Cloudflare Tunnel.

Cosa devo fare se il test XSS mostra effettivamente la finestra di avviso popup?

Significa che il codice inserisce l’input dell’utente nella pagina senza eseguire l’escape dei caratteri speciali HTML (<, >, &, ", '). Se usi JavaScript puro, non usare mai element.innerHTML = input, ma usa element.textContent = input. Se usi template engine o framework (React, Vue, Jinja2, Blade), assicurati che la sanitizzazione automatica non sia stata disattivata manualmente.

Come posso automatizzare questi controlli per ogni futuro aggiornamento del sito?

Puoi integrare strumenti gratuiti di SAST (Static Application Security Testing) come GitHub CodeQL o semgrep nelle tue GitHub Actions. In questo modo, ogni volta che aggiungi nuovo codice generato dall’IA, la piattaforma eseguirà una scansione automatica bloccando eventuali vulnerabilità prima del rilascio.

In che ordine conviene fare l’audit gratuito di un sito fatto con l’IA?

Parti dal codice (segreti e pattern pericolosi), poi header e TLS sul dominio pubblico (Mozilla Observatory e SSL Labs), infine i test empirici XSS/SQLi solo su tua applicazione. Così non perdi tempo a “passare” uno scan online mentre le chiavi sono ancora nel repository o .env è scaricabile.

---

Prossimi passi consigliati

• Approfondisci le basi della sicurezza del codice IA consultando la guida sul Vibe coding e i rischi del codice generato dall’IA.
• Esamina la lista rapida delle 7 falle di sicurezza più comuni nel codice dell’IA per riconoscere a colpo d’occhio le scorciatoie algoritmiche.
• Isola l’ambiente di esecuzione locale: guida all’installazione di Python su Windows, guida all’installazione di Python su macOS, guida all’installazione di Python su Linux, poi Ambienti virtuali Python (venv) in 5 minuti.