Verificare la sicurezza del sito senza hackerare nulla

Controlli di sicurezza passivi per e-commerce: scadenza certificato TLS, HSTS, CSP, nosniff, cookie, contenuti misti, jQuery obsoleto, security.txt e DMARC.

Redazione FixReports11 min di lettura

Puoi verificare dall’esterno buona parte della configurazione di sicurezza di un negozio online leggendo ciò che il sito invia già a ogni visitatore: il certificato TLS, i reindirizzamenti, gli header delle risposte HTTP, i cookie, gli script che carica e i record DNS pubblici. Questi controlli passivi non inviano traffico di attacco e non richiedono alcun login, quindi non pesano sul negozio più di una normale visita. Individuano lacune di configurazione come un certificato in scadenza, l’assenza di HSTS, cookie non sicuri, contenuti misti o una versione di jQuery con vulnerabilità note. Non sono un penetration test e non possono dimostrare che un negozio sia sicuro.

Punti chiave

Cosa si intende per controllo di sicurezza passivo?

Un controllo passivo si limita a leggere ciò che il sito o il suo DNS restituiscono a una normale richiesta.

Significa caricare le pagine pubbliche, leggere il certificato e gli header di risposta, elencare i cookie e gli script impostati da una pagina e interrogare i record DNS pubblici. Un controllo passivo non tenta di indovinare password, non invia payload di injection, non sonda gli URL di amministrazione e non esegue scansioni delle porte. Tutto ciò che segue si può fare con un browser, curl, openssl e dig.

Come si controllano il certificato TLS e la sua scadenza?

Leggi direttamente date e nomi del certificato e assicurati che il rinnovo sia automatico.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Verifica che notAfter sia ben lontano nel futuro, che il certificato copra sia example.com sia www.example.com se li usi entrambi (il visualizzatore di certificati del browser elenca i nomi) e che il browser non mostri avvisi. La durata dei certificati si sta riducendo in base ai Baseline Requirements del CA/Browser Forum (sezione 6.3.2, versione 2.3.1 a ottobre 2026), a seguito del Ballot SC-081v3 (si apre in una nuova scheda), adottato l’11 aprile 2025:

Certificato emessoValidità massima
Prima del 15 marzo 2026398 giorni
Dal 15 marzo 2026 al 14 marzo 2027200 giorni
Dal 15 marzo 2027 al 14 marzo 2029100 giorni
Dal 15 marzo 202947 giorni

Con durate così brevi il rinnovo manuale diventa rischioso, quindi verifica che il tuo hosting o il tuo strumento per i certificati esegua il rinnovo in automatico. Verifica anche che l’HTTP semplice reindirizzi a HTTPS:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

Ti serve una risposta 301 (o 308) con un header location che inizi con https://.

Quali header di sicurezza dovrebbe inviare un negozio online?

Un piccolo insieme di header di risposta blocca gli attacchi più comuni lato browser a un costo quasi nullo.

HeaderCosa faValore tipicoFonte
Strict-Transport-SecurityDice ai browser di usare solo HTTPS e impedisce agli utenti di ignorare gli errori del certificatomax-age=31536000; includeSubDomainsMDN (si apre in una nuova scheda)
Content-Security-Policy: frame-ancestorsControlla quali siti possono incorporare le tue pagine, proteggendo dal clickjackingframe-ancestors 'self'MDN (si apre in una nuova scheda)
X-Frame-OptionsControllo del framing più vecchio; secondo OWASP, nei browser che supportano frame-ancestors è quest’ultimo a renderlo obsoletoDENY o SAMEORIGINOWASP (si apre in una nuova scheda)
X-Content-Type-OptionsImpedisce il MIME sniffing e blocca script e fogli di stile serviti con il tipo sbagliatonosniffMDN (si apre in una nuova scheda)
Referrer-PolicyLimita quanta parte dei tuoi URL viene inviata ad altri sitistrict-origin-when-cross-originOWASP
X-XSS-ProtectionHeader del filtro XSS dei browser; secondo OWASP può creare vulnerabilità XSS in siti altrimenti sicuriNon impostarlo, oppure 0OWASP

Controlla cosa invia il tuo negozio:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Due avvertenze. includeSubDomains blocca qualsiasi sottodominio che funziona solo su HTTP, quindi controlla prima i sottodomini. Il preload HSTS richiede un max-age di almeno 31536000 e includeSubDomains, quindi aggiungi preload solo quando tutti i sottodomini sono pronti per HTTPS. Una CSP completa che limita gli script vale la pena di averla, ma OWASP fa notare che è complessa da configurare e mantenere, e i negozi con molte app devono testarla con attenzione.

I cookie di sessione e del carrello dovrebbero avere tutti e tre gli attributi, e puoi vederli negli header di risposta Set-Cookie.

AttributoEffetto (secondo MDN (si apre in una nuova scheda))Dove conta
SecureInviato solo su HTTPS; i siti su HTTP semplice non possono impostarloOgni cookie di un negozio su HTTPS
HttpOnlyJavaScript non può leggerlo tramite document.cookie, il che aiuta contro gli attacchi XSSSessioni di login e carrelli
SameSite=Lax o StrictLimita i casi in cui il cookie viene inviato nelle richieste cross-siteSessioni; Strict è adatto ai cookie di autenticazione e del carrello
SameSite=NoneInviato nelle richieste cross-site; deve essere combinato con SecureSolo le funzionalità di terze parti incorporate che ne hanno bisogno

Se l’attributo SameSite non è impostato, i browser trattano il cookie come Lax. I cookie che i tuoi script devono leggere non possono essere HttpOnly, quindi concentrati su quelli che identificano un cliente che ha effettuato l’accesso o un amministratore.

curl -sI https://example.com/ | grep -i "^set-cookie"

Gli strumenti per sviluppatori del browser mostrano le stesse informazioni, compresi i cookie impostati dagli script dopo il caricamento della pagina.

Come si trovano i contenuti misti?

Per contenuto misto (mixed content) si intende qualsiasi risorsa caricata su HTTP in una pagina servita su HTTPS, e la console del browser lo elenca.

MDN (si apre in una nuova scheda) lo divide in due gruppi. Immagini, audio e video sono “aggiornabili” (upgradable): i browser li richiedono automaticamente su HTTPS. Script, fogli di stile, iframe, font e richieste fetch() sono “bloccabili” (blockable): i browser li bloccano, e smette di funzionare tutto ciò che ne dipendeva. Vengono bloccate anche le richieste aggiornate verso un semplice indirizzo IP.

Per trovarlo, apri la console sui template principali (home page, collezione, prodotto, carrello) e cerca http:// nel codice del tema, nei contenuti delle pagine e nelle impostazioni delle app. Il centro assistenza di Shopify spiega che qualsiasi pagina del negozio con una risorsa non distribuita su HTTPS è considerata non sicura (si apre in una nuova scheda) e consiglia di ospitare le risorse su Shopify o di servirle su HTTPS. Su WooCommerce, se il sito è mai stato su http://, controlla i contenuti dei vecchi articoli e le opzioni del tema.

Come si individuano le librerie JavaScript obsolete con CVE note?

Elenca le librerie caricate da ogni pagina, leggine le versioni e confrontale con il National Vulnerability Database.

Inizia da jQuery. Nella console del browser, $.fn.jquery restituisce la versione caricata (jQuery API (si apre in una nuova scheda)). Le versioni da segnalare:

CVEVersioni interessateProblemaPunteggio NVD (v3.1)
CVE-2020-11022 (si apre in una nuova scheda)Dalla 1.12.0 a prima della 3.5.0Passare HTML non attendibile a metodi come .html() o .append() può eseguire codice6,1 (Medium)
CVE-2020-11023 (si apre in una nuova scheda)Dalla 1.0.3 a prima della 3.5.0Come sopra, per HTML che contiene elementi <option>; nel catalogo KEV della CISA dal 23 gennaio 20256,1 (Medium)
CVE-2019-11358 (si apre in una nuova scheda)Prima della 3.4.0Prototype pollution tramite jQuery.extend(true, ...)6,1 (Medium)

Entrambi i problemi del 2020 sono stati corretti in jQuery 3.5.0. Una versione vulnerabile significa che il codice difettoso è presente; se possa essere sfruttato dipende da come il sito gli passa i dati. WordPress include jQuery 3.5.1 dalla versione 5.6 (si apre in una nuova scheda), quindi un jQuery vecchio su un negozio WooCommerce indica un WordPress non aggiornato oppure un tema o un plugin che carica una propria copia. Su Shopify, controlla i file del tema e le app che iniettano script.

Che cos’è security.txt e serve al tuo negozio?

È un file di testo semplice che spiega ai ricercatori di sicurezza come segnalarti una vulnerabilità.

La RFC 9116 (si apre in una nuova scheda) (aprile 2022, una RFC di tipo Informational, quindi seguirla è facoltativo) stabilisce che il file deve essere servito su HTTPS in /.well-known/security.txt come text/plain. Contact ed Expires sono obbligatori, e la RFC raccomanda una data Expires a meno di un anno di distanza.

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

Su WooCommerce puoi caricare il file sul tuo server. Su una piattaforma in hosting gestito, verifica se puoi pubblicare un file in quel percorso; in caso contrario, un contatto per la sicurezza chiaramente indicato nella pagina dei contatti è comunque utile.

Come protegge DMARC il tuo negozio dallo spoofing delle email?

DMARC ti permette di chiedere ai provider di posta di mettere in quarantena o rifiutare le email che usano il tuo dominio nell’indirizzo From senza superare SPF o DKIM allineati.

Un record con p=none raccoglie solo i report; non blocca la posta falsificata. I clienti si aspettano conferme d’ordine e reimpostazioni della password dal tuo dominio, quindi vale la pena bloccare un messaggio di phishing che mostra esattamente il tuo dominio. Controlla la tua policy con dig +short TXT _dmarc.example.com e consulta la RFC 9989 (si apre in una nuova scheda) per la specifica. DMARC non copre i domini simili (lookalike), ma solo il dominio che pubblica il record.

Cosa gestisce Shopify e cosa controlli tu su WooCommerce?

Shopify gestisce i server dietro i suoi negozi, mentre un negozio WooCommerce in self-hosting lascia le impostazioni del server a te e al tuo hosting.

ControlloShopifyWooCommerce (self-hosted)
Certificato TLSGratuito per tutti i domini aggiunti a Shopify (si apre in una nuova scheda); per i domini di terze parti possono servire fino a 48 oreIl tuo hosting o una tua configurazione
Reindirizzamento da HTTP a HTTPSPiattaformaImpostazioni del server web, della CDN o dell’hosting
Header di sicurezzaInviati dai server di ShopifyServer web, CDN o un plugin
Flag dei cookieI cookie propri di Shopify sono impostati dalla piattaforma; quelli di app e tema sono responsabilità tuaCore di WordPress, plugin e server
Contenuti misti e librerie JSIl tuo tema, i tuoi contenuti e le tue appIl tuo tema, i tuoi contenuti e i tuoi plugin
security.txt e DMARCIl tuo dominio e il tuo DNSIl tuo dominio e il tuo DNS

Quando a ottobre 2026 abbiamo controllato diversi negozi ospitati su Shopify, le loro risposte includevano HSTS con un max-age di circa 91 giorni, X-Content-Type-Options: nosniff e una CSP con upgrade-insecure-requests, mentre frame-ancestors variava da negozio a negozio. Shopify dichiara di avere la certificazione di conformità PCI DSS di livello 1 (si apre in una nuova scheda). Il tema e le app installate restano una tua responsabilità.

Su WooCommerce, la guida all’hardening (si apre in una nuova scheda) di WordPress raccomanda di mantenere aggiornati WordPress e i plugin, eliminare i plugin che non usi e chiedere al tuo hosting quali precauzioni di sicurezza adotta.

Perché questo non è un penetration test?

Un penetration test tenta attivamente degli attacchi; i controlli passivi si limitano a osservare.

La NIST SP 800-115 definisce il penetration test come un test di sicurezza in cui i valutatori imitano attacchi reali per trovare modi di aggirare le funzioni di sicurezza di un sistema (glossario NIST (si apre in una nuova scheda)). I controlli passivi non possono vedere difetti lato server nei plugin, password di amministrazione deboli o riutilizzate, l’assenza dell’autenticazione a due fattori, controlli di accesso difettosi o codice vulnerabile che non compare mai nel sorgente della pagina. Usali come base di riferimento da ripetere in qualsiasi momento. Per garanzie più approfondite, commissiona un penetration test con un perimetro definito per iscritto, su sistemi di tua proprietà o che sei autorizzato a testare.

Una scansione gratuita esegue un primo controllo del tuo negozio. Il report sulla sicurezza del sito copre i controlli passivi di questo articolo, da TLS e reindirizzamenti fino a header, cookie, contenuti misti, librerie obsolete, security.txt e DMARC, con le correzioni per ogni problema rilevato. Come qualsiasi verifica passiva, non può garantire che un negozio sia sicuro.

Domande frequenti

I controlli di sicurezza passivi mettono a rischio il mio negozio?

Non più di una normale visita. Richiedono le stesse pagine pubbliche e gli stessi record DNS che richiederebbe qualsiasi browser o server di posta, e non tentano di effettuare l’accesso né di inviare payload di attacco.

Posso aggiungere header di sicurezza su Shopify?

Gli header di risposta del negozio provengono dai server di Shopify, quindi se ne manca uno che ti serve contatta l’assistenza di Shopify. Un tag CSP <meta> nel tema può aggiungere alcune direttive, ma MDN fa notare che frame-ancestors non è supportata in <meta>.

Una vecchia versione di jQuery significa che il mio negozio è stato hackerato?

No. Significa che viene caricato codice con vulnerabilità note, il che aumenta il rischio se il sito passa HTML non attendibile ai metodi interessati. Aggiornalo, oppure rimuovi il tema o il plugin che lo carica.

Per quanto tempo può essere valido oggi un certificato TLS?

I certificati pubblicamente attendibili emessi dal 15 marzo 2026 possono essere validi al massimo 200 giorni. Il limite scende a 100 giorni dal 15 marzo 2027 e a 47 giorni dal 15 marzo 2029.

Il file security.txt è obbligatorio?

La RFC 9116 è una RFC di tipo Informational, quindi secondo lo standard pubblicare il file è facoltativo. Pubblicarlo costa poco e offre ai ricercatori un modo chiaro per contattarti.

Una scansione passiva senza problemi significa che il mio negozio è sicuro?

No. Mostra che la configurazione pubblica sembra corretta. Vulnerabilità lato server, sicurezza degli account e difetti nella logica di business richiedono altri test.

Fonti

Tutte le guide