Come sapere se il tuo sito è sicuro in 5 minuti

Non serve essere esperti di sicurezza per sapere se il tuo sito ha i difetti più comuni. Con un browser, un terminale e cinque minuti puoi verificare ciò che un attaccante automatizzato prova nei primi secondi: se il traffico è cifrato, se mancano header, se ci sono chiavi nel codice, se la tua API accetta richieste da qualsiasi parte e se ci sono file che non dovrebbero essere lì. Questa guida ti porta passo dopo passo, con il comando esatto, cosa significa ogni risultato e cosa fare in base a quello che trovi. Alla fine hai come dare le priorità e quali cose questo test non rileva.

Minuto 1: HTTPS e reindirizzamento

Scrivi il tuo dominio con http:// davanti, senza la s. Deve portarti subito alla versione https://. Dal terminale:

curl -sI http://tuodominio.com | head -3
curl -sI http://tuodominio.com/prezzi | head -3

Entrambe le risposte devono essere un 301 con Location: https://.... Se la seconda non reindirizza, il tuo reindirizzamento copre solo la home. Poi, con https://, guarda se compare l'header Strict-Transport-Security: dice al browser di non usare più HTTP. Se sei su Vercel, Netlify o Cloudflare, il reindirizzamento è già impostato e l'HSTS lo devi aggiungere tu. Cosa significa ogni dettaglio del certificato, in cosa significa davvero il tuo voto TLS.

Minuto 2: header di sicurezza

curl -sI https://tuodominio.com | grep -iE "strict-transport|content-type-options|frame-options|referrer-policy|content-security-policy|permissions-policy"

Dovrebbero uscire almeno cinque righe. Ognuna che manca è una protezione che il browser non può applicare: senza X-Frame-Options il tuo sito può essere incorporato in un altro per ingannare i tuoi utenti; senza X-Content-Type-Options il browser indovina i tipi di file; senza Content-Security-Policy qualsiasi script iniettato gira senza freni. Se non ti piace il terminale, incolla il tuo URL nell'analizzatore di header. Il significato di ciascuno, in header HTTP spiegati per umani.

Minuto 3: segreti nel JavaScript

Apri il tuo sito, tasto destro, "Visualizza sorgente". Cerca .js per vedere quali file di script carica, apri il principale e usa la ricerca del browser con questi termini:

sk_live   sk_test   service_role   AKIA   eyJhbGci   api_key   apiKey   secret   password

Dal terminale puoi farlo in un colpo solo su tutti gli script della home:

curl -s https://tuodominio.com/ | grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | while read s; do
  case "$s" in http*) u="$s";; /*) u="https://tuodominio.com$s";; *) u="https://tuodominio.com/$s";; esac
  curl -s "$u" | grep -oE "sk_live_[A-Za-z0-9]+|service_role|AKIA[A-Z0-9]{16}|eyJhbGciOi[A-Za-z0-9_-]{20,}" | head -3
done

Ci sono cose che è normale trovare: la chiave pubblica di Stripe (pk_live), la chiave anon di Supabase o la configurazione di Firebase sono progettate per stare nel browser. Quello che non deve mai comparire: sk_live, service_role, chiavi AWS (AKIA), token di OpenAI o qualsiasi cosa si chiami secret. Se ne trovi una, considerala compromessa e ruotala prima di toglierla dal codice. La lista completa è in segreti che la tua app fa trapelare nel browser.

Minuto 4: CORS e cookie

Il CORS decide quali altri siti possono fare richieste alla tua API dal browser. Richiedi un tuo endpoint fingendo di arrivare da un altro dominio:

curl -sI -H "Origin: https://evil.example" https://tuodominio.com/api/me | grep -i "access-control"

Se risponde Access-Control-Allow-Origin: https://evil.example o * insieme a Access-Control-Allow-Credentials: true, qualsiasi sito può leggere i dati dei tuoi utenti con la loro sessione. L'origine permessa deve essere la tua e solo la tua. Già che ci sei, guarda i cookie nella risposta di login o negli strumenti del browser: quelli di sessione hanno bisogno di Secure, HttpOnly e SameSite=Lax o Strict. Il dettaglio in CORS configurato male.

Minuto 5: file esposti

Gli strumenti e i deploy a metà lasciano tracce. Prova questi percorsi e guarda che codice restituiscono:

for p in .env .env.local .env.production .git/config .DS_Store config.json backup.zip database.sql phpinfo.php server-status api/debug api/seed swagger.json; do
  printf "%-20s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://tuodominio.com/$p"
done

Quello che vuoi vedere è 404 (o 301 verso la tua pagina di errore). Un 200 su .env o .git/config è grave: il primo contiene le tue credenziali e il secondo permette di scaricare il codice sorgente completo. Un 200 su swagger.json o api/debug non è una fuga in sé, ma dà a un attaccante la mappa della tua API.

Minuto extra: quello che vedono i bot

Se ti avanza un minuto, guarda /robots.txt e /sitemap.xml: che esistano, che non blocchino tutti e che la sitemap abbia solo pagine che vuoi indicizzare. Non è sicurezza in senso stretto, ma un Disallow: / dimenticato dalla fase di test costa mesi di posizionamento.

Come dare priorità a quello che trovi

Non tutto pesa allo stesso modo. Questo è l'ordine che usiamo:

Critico, oggi stesso. Una chiave segreta nel JavaScript; .env o .git accessibili; un'API che accetta qualsiasi origine con credenziali. Ruota, cancella, chiudi. Poi controlla se qualcuno l'ha usata.
Alto, questa settimana. Nessun reindirizzamento a HTTPS; cookie di sessione senza HttpOnly o Secure; rotte di debug in produzione.
Medio, questo mese. Header mancanti; niente HSTS; certificato in scadenza senza rinnovo automatico.
Basso. Documentazione API esposta, robots.txt e sitemap trascurati, header che rivelano la versione del server.

Cosa questi cinque minuti non rilevano

Sii onesto con i limiti. Questo test guarda la superficie che chiunque può vedere dall'esterno. Non verifica se il tuo database lascia leggere righe di altri utenti (in Supabase è l'RLS, in Firebase sono le regole), se le tue dipendenze hanno vulnerabilità note, se la tua logica di business permette di saltare un pagamento o se un modulo accetta qualsiasi input. Per il primo punto, la guida Supabase e quella Firebase spiegano come testarlo. Per il resto bisogna guardare il codice, e la checklist prima del lancio raccoglie l'essenziale.

Scanaris fa questo e altre quaranta cose in 30 secondi

I cinque passi qui sopra sono il nucleo di ciò che Scanaris verifica, più una quarantina di test che non stanno in cinque minuti: ogni header separatamente, i segreti con pattern di decine di servizi, i file esposti con una lista molto più lunga, TLS completo, cookie, CORS su più rotte, e in più lo stato della tua SEO e della tua visibilità per l'IA. Per ogni errore ti dà un fix prompt da incollare in Lovable, Bolt, Cursor o v0 con la modifica esatta, e può ripetere la scansione ogni giorno e avvisarti se qualcosa peggiora. Sono tutti controlli in sola lettura su ciò che è già pubblico nel tuo sito.

Domande frequenti

È legale scansionare il mio sito così?

Sì. Tutto quello che c'è qui sono richieste normali che qualsiasi browser fa; stai solo leggendo ciò che il tuo server risponde già a chiunque. Fallo solo su domini tuoi o con il permesso.

E se non so usare il terminale?

I passi 1, 3 e 5 si possono fare dal browser (scrivere URL e visualizzare il sorgente), il 2 con l'analizzatore di header gratuito, e il 4 è l'unico che lo richiede. Oppure lascia che uno scanner lo faccia per te.

Ogni quanto dovrei ripeterlo?

Ogni volta che fai il deploy di qualcosa di rilevante e, come minimo, una volta al mese. Le app create con l'IA cambiano in fretta, e una rigenerazione del codice può reintrodurre un difetto che avevi già sistemato.