109 controlli automatici su ogni scansione

Trasporto cifrato, header di protezione, segreti dimenticati nel codice e backend esposti: i punti dove i siti fatti in fretta (soprattutto con l’AI) si fanno male davvero.

• Redirect automatico a HTTPS. La versione http:// deve portare subito a https://, altrimenti il traffico può viaggiare in chiaro.
• Validità del certificato TLS. Certificato scaduto o non valido = avviso “sito non sicuro” nel browser e visitatori in fuga.
• Contenuti misti HTTP su pagina HTTPS. Script o immagini caricati in chiaro dentro una pagina cifrata aprono la porta a manomissioni.
• HSTS (Strict-Transport-Security). Dice al browser di usare sempre HTTPS, anche al primo accesso.
• Scadenza del certificato TLS. Ti avvisiamo se il certificato scade entro 30 giorni: alla scadenza il sito si blocca di colpo per tutti.
• Record SPF (anti-spoofing email). Senza SPF chiunque può inviare email a nome del tuo dominio, e le tue finiscono in spam.
• Policy DMARC del dominio. Dice ai server di posta cosa fare con le email contraffatte: assente o in sola osservazione, lo spoofing passa.
• Librerie JS con CVE note. jQuery, Bootstrap, Lodash e altre in versioni con vulnerabilità pubbliche documentate (con sigla CVE).
• Librerie JS a fine vita (EOL). Librerie fuori supporto (AngularJS, Vue 2): le nuove falle non riceveranno mai una patch.
• Content-Security-Policy. La difesa principale contro script iniettati (XSS): senza, uno script ostile può fare tutto.
• Protezione clickjacking (X-Frame-Options). Impedisce che il tuo sito venga incorniciato in pagine truffa per rubare click.
• MIME sniffing (X-Content-Type-Options). Evita che il browser “indovini” i tipi di file ed esegua contenuti che non dovrebbe.
• Referrer-Policy. Controlla quali informazioni di navigazione passi ai siti terzi.
• Permissions-Policy. Limita l’accesso a fotocamera, microfono e sensori da parte di script terzi.
• Versioni del software server esposte. Dichiarare versione di server o framework regala agli attaccanti la lista degli exploit da provare.
• File .env raggiungibile pubblicamente. Il file con password e chiavi API scaricabile da chiunque: uno degli errori più gravi (e più comuni).
• Cartella .git raggiungibile pubblicamente. Con la cartella .git esposta si scarica l’intero codice sorgente, segreti inclusi.
• Source map esposte in produzione. Le mappe di debug rivelano il codice originale e spesso commenti e segreti.
• Chiavi AWS nel codice pubblico. Una access key AWS nel bundle JavaScript = conto cloud di qualcun altro a tua insaputa.
• Chiavi segrete Stripe nel codice pubblico. Una chiave segreta Stripe esposta permette rimborsi, addebiti e accesso ai dati di pagamento.
• API key Google esposte. Chiavi Google senza restrizioni possono generare costi e abusi sui tuoi servizi.
• Chiave service-role Supabase esposta. La service-role key scavalca ogni regola di sicurezza del database: nel frontend è un disastro.
• Row Level Security Supabase. Tabelle leggibili senza login: verifichiamo che le regole RLS proteggano davvero i dati (solo il fatto, mai i dati).
• Regole di accesso database Firebase. Realtime Database con regole aperte = dati di tutti gli utenti pubblici. Controlliamo senza scaricare nulla.
• Robustezza della Content-Security-Policy. Una CSP con ’unsafe-inline’ o sorgenti aperte sembra protezione ma non ferma nulla: la falsa sicurezza è peggio dell’assenza.
• Isolamento della finestra (Cross-Origin-Opener-Policy). Impedisce che una pagina aperta dal tuo sito mantenga il controllo della tua scheda.
• Flag di sicurezza dei cookie (Secure, HttpOnly, SameSite). Senza questi flag un cookie di sessione è leggibile da JavaScript e allegato alle richieste di altri siti: furto di account e CSRF.
• Integrità degli script di terze parti (SRI). Se il CDN che ospita una libreria viene compromesso (è successo a polyfill.io, 100k+ siti), senza integrity il browser esegue il codice sostituito.
• Invio dei form su connessione cifrata. Un form che spedisce in http:// da una pagina https:// fa viaggiare i dati in chiaro, e il browser avvisa l’utente all’invio.
• Link esterni protetti (rel="noopener"). Senza noopener la pagina che apri può cambiare l’indirizzo della tua scheda mentre l’utente guarda altrove.
• Firma DKIM delle email. Senza DKIM le tue email si autenticano peggio e finiscono in spam più spesso; con DKIM il destinatario verifica che il messaggio sia davvero tuo.
• Report DMARC attivi (rua). Una policy DMARC senza indirizzo per i report è cieca: non sai chi sta scrivendo a nome tuo e non puoi mai irrigidirla.
• Cifratura obbligatoria tra server di posta (MTA-STS). Tra server di posta il TLS è facoltativo: senza MTA-STS un attaccante può forzare l’invio in chiaro e leggere la posta in transito.
• DNSSEC. Firma le risposte DNS del dominio: senza, è possibile dirottare i visitatori su un server che non è il tuo.
• Record CAA. Dichiara quali autorità possono emettere certificati per il tuo dominio. Senza, qualsiasi CA al mondo può emetterne uno a tuo nome.

Le basi di conformità che il Garante (e i tuoi utenti) si aspettano da qualsiasi sito europeo.

• Banner di consenso cookie. Se usi cookie non tecnici serve un banner di consenso: la sua assenza è la violazione più visibile.
• Privacy policy raggiungibile. Un’informativa privacy linkata e leggibile è obbligatoria se tratti qualsiasi dato personale.
• Tracker attivi prima del consenso. Analytics e pixel che partono prima del clic su “Accetta” violano il GDPR: li rileviamo.
• Cookie policy come documento separato. Il Garante chiede un’informativa cookie a sé, con elenco, durate e terze parti: un paragrafo dentro la privacy policy non basta.
• Termini e condizioni raggiungibili. Per chi vende sono obbligatori; per tutti gli altri sono l’unico documento che definisce cosa prometti e cosa no.
• Dati societari nel footer (P. IVA, ragione sociale). L’art. 2250 c.c. li impone anche online, ed è il primo controllo che fa chi sta decidendo se fidarsi di te.
• Font caricati senza trasferire dati a Google. Google Fonts da CDN manda l’IP di ogni visitatore negli USA senza consenso: è la violazione dietro migliaia di diffide in Europa.
• Consenso privacy nei form di raccolta dati. Un form che chiede email o telefono senza checkbox né informativa raccoglie dati senza base giuridica dimostrabile.

Quello che un visitatore (o un cliente) incontra davvero: link rotti, errori, vicoli ciechi.

• Link interrotti. Link che portano a pagine inesistenti: fiducia giù e SEO penalizzata.
• Errori JavaScript in console. Errori in console spesso significano funzionalità rotte che nessuno ha notato.
• Stack trace o errori tecnici visibili. Messaggi d’errore grezzi in pagina spaventano gli utenti e rivelano dettagli interni.
• Status HTTP 404 sulle pagine inesistenti. Rispondere 200 su un indirizzo che non esiste (soft 404) fa indicizzare a Google pagine vuote e inventate.
• Pagina 404 personalizzata. La 404 nuda del server è un vicolo cieco: nessun messaggio, nessun link per rientrare nel sito.
• Canale di contatto raggiungibile. Email, form o pagina contatti: senza, il sito perde credibilità (e clienti).
• Favicon presente. L’icona nella scheda del browser e nei risultati di ricerca: assente, il sito sembra incompleto.
• Tempo di risposta del server. Risposte lente frustrano gli utenti prima ancora che la pagina si carichi.
• Percorsi utente senza vicoli ciechi. Simuliamo la navigazione principale: bottoni che non portano da nessuna parte, flussi interrotti.
• Il dominio riceve le email pubblicate sul sito. Indirizzi @tuodominio sul sito ma niente record MX: quelle email rimbalzano e le richieste dei clienti si perdono.
• Raggiungibilità su IPv6. Diverse reti mobili sono ormai IPv6-only: senza record AAAA passano da traduttori intermedi, con latenza e guasti in più.
• Ridondanza dei name server. Un solo name server è un punto singolo di guasto per sito ed email insieme. Lo standard ne chiede almeno due.
• Scadenza del dominio. Un dominio scaduto porta giù sito e posta, e dopo il periodo di grazia chiunque può registrarlo al posto tuo.
• Immagini che caricano davvero. Le immagini che rispondono con errore lasciano riquadri vuoti: su una scheda prodotto è il segnale di abbandono più immediato.
• Protocollo HTTP/2 o superiore. Su HTTP/1.1 il browser accoda le richieste una alla volta: su una pagina con decine di file è un ritardo su ogni visita.

I fondamentali per essere trovati su Google e presentarsi bene quando il link viene condiviso.

• Tag <title> della pagina. Il titolo è la prima cosa che Google mostra: assente o vuoto, sei invisibile.
• Meta description. La descrizione sotto il titolo nei risultati di ricerca: senza, decide Google per te.
• Struttura dei titoli H1. Un solo H1 chiaro per pagina: zero o troppi confondono i motori di ricerca.
• Gerarchia dei titoli (h1 → h2 → h3). I titoli non devono saltare livelli: la gerarchia corretta è la mappa che Google e gli screen reader usano per capire la pagina.
• URL canonico. Evita che la stessa pagina appaia come duplicata, diluendo il posizionamento.
• File robots.txt. Dice ai motori cosa possono esplorare: la sua assenza è un segnale di trascuratezza.
• robots.txt non blocca i motori di ricerca. Un "Disallow: /" dimenticato dallo staging cancella il sito da Google, e dalla pagina non si vede.
• Sitemap dichiarata nel robots.txt. La direttiva Sitemap: è come un crawler che non ti conosce trova subito tutte le pagine.
• Sitemap XML. La mappa del sito aiuta Google a trovare e indicizzare tutte le pagine.
• Dati strutturati JSON-LD (schema.org). Dichiarano a Google e agli assistenti AI cosa sei: senza, niente risultati arricchiti nella SERP.
• Formato dei dati strutturati JSON-LD. Un JSON-LD con un errore di sintassi o senza @context/@type viene scartato in silenzio: markup inutile.
• Anteprima social (Open Graph). Senza Open Graph il link condiviso su social e chat appare spoglio, senza immagine né titolo.
• Lingua dichiarata della pagina. L’attributo lang aiuta motori di ricerca e screen reader a capire il contenuto.
• Viewport per dispositivi mobili. Senza meta viewport il sito appare minuscolo su smartphone: penalizzazione mobile immediata.
• Indicizzabilità sui motori di ricerca. Un noindex dimenticato (capita spesso ai siti generati) ti cancella da Google.
• Accesso dei crawler AI (ChatGPT, Claude, Perplexity). Se il robots.txt li blocca — spesso per un default della CDN — il tuo sito non può essere citato nelle risposte degli assistenti.
• Identità dell’attività nei dati strutturati. Il nodo Organization o LocalBusiness dice ai motori (e alle AI) chi sei: senza, ti riassumono senza citarti.
• Lunghezza del title nei risultati di ricerca. Oltre i 65 caratteri Google taglia, sotto i 25 riscrive: in entrambi i casi il titolo che hai scelto non è quello che l’utente legge.
• Lunghezza della meta description. Troppo corta e Google la sostituisce, troppo lunga e la tronca a metà frase: è il tuo unico spazio pubblicitario gratuito.
• Completezza dell’anteprima social (immagine, testo, URL). Open Graph parziale = anteprima mutila: senza og:image il link condiviso esce come un riquadro di solo testo.
• Anteprima su X/Twitter (Twitter Card). Senza twitter:card il link su X esce nudo invece che con l’anteprima grande.
• Dichiarazione delle lingue alternative (hreflang). Se il sito è multilingua, un hreflang sbagliato fa competere le versioni tra loro e porta gli utenti nella lingua sbagliata.

La velocità percepita dai tuoi utenti, misurata con Google PageSpeed.

• Velocità di caricamento mobile. Core Web Vitals via PageSpeed (strategia mobile, la misura che Google usa per il ranking): un sito lento perde visitatori e posizioni.
• Velocità di caricamento desktop. Stessa misura con strategia desktop: su schermo grande le aspettative di velocità sono ancora più alte.
• Formati immagine moderni (WebP/AVIF). Immagini in JPEG/PNG dove i formati moderni peserebbero molto meno, a parità di qualità.
• Peso e dimensioni delle immagini. Immagini compresse male o servite più grandi di come vengono mostrate: peso inutile a ogni visita.
• JavaScript inutilizzato. Codice scaricato ed elaborato che la pagina non usa: rallenta proprio i dispositivi più lenti.
• Risorse che bloccano il render. CSS e script sincroni che tengono la pagina bianca mentre il contenuto sarebbe già pronto.
• Compressione testo (gzip/brotli). Senza compressione HTML, CSS e JS pesano il doppio: il fix è una riga di configurazione server.
• Cache degli asset statici. Asset riscaricati a ogni visita invece che riletti dalla cache: penalizza i visitatori di ritorno.
• Peso totale della pagina. Oltre i 3MB il caricamento si sente su qualsiasi connessione non perfetta.
• Core Web Vitals reali (dati utenti). I dati CrUX degli utenti Chrome veri del sito: la misura che Google usa davvero nel ranking.
• Distribuzione tramite CDN. Senza CDN ogni visitatore scarica tutto dal server di origine, e un picco di traffico non ha cuscinetto.
• Testo visibile mentre caricano i font. Senza font-display il browser tiene il testo invisibile fino a tre secondi: pagina impaginata ma muta.
• Caricamento differito delle immagini. Senza loading="lazy" il browser scarica subito anche le immagini in fondo pagina, rubando banda a quelle che si stanno guardando.
• Dimensioni dichiarate sulle immagini. Senza width e height il contenuto salta mentre le immagini arrivano: è la causa numero uno del layout instabile che Google penalizza.
• Minificazione di JavaScript e CSS. Codice spedito con indentazione e commenti è peso inutile su ogni visita: si risolve con un passaggio di build.

Lo European Accessibility Act si applica dal 28 giugno 2025 e la Legge Stanca è stata estesa ai privati: l’accessibilità è un obbligo con scadenza già passata. Questi controlli leggono il markup della pagina e trovano le barriere più comuni.

• Testo alternativo sulle immagini. Senza alt, chi non vede l’immagine perde l’informazione: è il primo criterio verificato in ogni controllo di conformità.
• Etichette sui campi dei form. Un campo senza etichetta viene annunciato come “casella di testo” e basta: su un form di pagamento è una barriera piena.
• Nome accessibile su bottoni e link di sola icona. Hamburger, X di chiusura, carrello: senza aria-label vengono letti come “pulsante” e nient’altro.
• Titolo descrittivo sugli iframe. Mappe e video incorporati senza title vengono annunciati come “frame”, senza dire cosa contengono.
• Intestazioni nelle tabelle di dati. Senza <th> un listino diventa una sequenza di numeri senza etichetta per chi lo ascolta.
• Zoom consentito su mobile. user-scalable=no impedisce di ingrandire la pagina: chi ha una vista ridotta non può leggerla dal telefono.
• Struttura della pagina (main, nav, header). I landmark sono la mappa che permette di saltare al contenuto invece di attraversare tutto il menu.
• Link “salta al contenuto”. Senza, chi naviga da tastiera attraversa intestazione e menu a ogni cambio di pagina.
• Ordine di tabulazione coerente. Un tabindex positivo crea una sequenza tutta sua che non corrisponde a quello che si vede a schermo.
• Audio e video in autoplay controllabili. L’audio che parte da solo copre la voce sintetica di chi usa uno screen reader e non si può fermare.
• Sottotitoli sui video. Senza sottotitoli il parlato è disponibile solo a chi lo sente — e alla maggioranza che guarda senza audio.
• Uso corretto degli attributi ARIA. Ruoli inventati o aria-hidden su elementi ancora raggiungibili da tastiera peggiorano le cose invece di migliorarle.
• Testo dei link comprensibile fuori contesto. Una lista di “clicca qui” non distingue niente, né per uno screen reader né per Google.
• Dichiarazione di accessibilità. È il documento che dichiara a che punto sei con la conformità e come segnalare una barriera. Per molti soggetti è obbligatorio.