AppurAI
Tutte le guide

Sito Web Sicuro: cos'è davvero e come costruirlo (guida completa)

Un sito web sicuro non è quello che "sembra" a posto, con il lucchetto verde nella barra e una grafica curata. È un sito costruito in modo che i dati degli utenti restino privati, che nessuno possa accedere a funzioni che non gli spettano e che una vulnerabilità banale non si trasformi in un disastro. La differenza è invisibile finché non succede qualcosa: un account rubato, un database svuotato, una chiave API finita nelle mani sbagliate.

In questa guida vediamo, senza gergo inutile, cosa rende sicuro un sito web, i pilastri su cui poggia, le minacce più comuni e il caso particolare dei siti nati con l'AI. È l'articolo di riferimento: da qui rimandiamo agli approfondimenti pratici.

Cosa significa avere un sito web sicuro

La sicurezza non è un interruttore che accendi una volta: è una proprietà del sistema, la somma di tante scelte. Gli esperti la riassumono in tre principi, la triade CIA:

  • Riservatezza: solo chi è autorizzato può vedere un dato (password, ordini, messaggi privati).
  • Integrità: nessuno può alterare i dati senza permesso, dal prezzo di un prodotto al saldo di un account.
  • Disponibilità: il sito resta accessibile a chi ne ha bisogno, anche sotto attacco o dopo un guasto.

Un sito è sicuro quando questi tre principi reggono anche mentre qualcuno prova, di proposito, a romperli. La sicurezza si costruisce a strati: se un livello cede, gli altri contengono il danno, e l'assenza di uno solo dei pilastri può bastare a farti male.

I pilastri di un sito web sicuro

Non serve implementarli tutti nello stesso giorno, ma sapere che esistono e capire quali ti mancano.

1. HTTPS e TLS: la connessione cifrata

L'HTTPS cifra il traffico tra il browser dell'utente e il tuo server. Senza, chiunque sia sulla stessa rete (il Wi-Fi di un bar) può leggere in chiaro password e dati. Oggi è il minimo sindacale: i browser marcano come "Non sicuro" i siti in semplice HTTP e Google li penalizza.

Un certificato TLS valido, però, non basta. Devi anche forzare il redirect da HTTP a HTTPS, così nessuno resta sulla versione non cifrata, e attivare l'header HSTS, che impone al browser di usare sempre la connessione sicura.

2. Autenticazione e gestione delle password

L'autenticazione risponde alla domanda "chi sei?". È il punto più attaccato di qualsiasi sito, perché è la porta d'ingresso. Le regole minime:

  • Le password degli utenti vanno salvate con hashing (bcrypt, Argon2, scrypt), mai in chiaro e mai con algoritmi obsoleti come MD5.
  • Serve una protezione contro i tentativi ripetuti di login (brute force): blocco temporaneo, ritardi progressivi, captcha.
  • L'autenticazione a due fattori (2FA) dovrebbe essere disponibile, almeno per gli account amministratori.

Una singola password admin debole o riutilizzata può vanificare tutto il resto.

3. Autorizzazione e controllo degli accessi

Se l'autenticazione dice "chi sei", l'autorizzazione dice "cosa puoi fare". Qui si annida una delle falle più insidiose: l'utente A che, cambiando un numero nell'URL, riesce a vedere l'ordine dell'utente B.

Il principio guida è il privilegio minimo: ogni utente, funzione e chiave deve avere solo i permessi strettamente necessari. Ogni endpoint che restituisce o modifica dati sensibili deve verificare, lato server, che chi lo chiama ne abbia il diritto. Non fidarti dei controlli fatti solo nel frontend: si aggirano in pochi secondi.

4. Protezione dei dati e privacy

Un sito sicuro protegge i dati non solo mentre viaggiano (HTTPS) ma anche mentre sono fermi nel database: cifrare quelli più sensibili, raccogliere solo ciò che serve davvero (minimizzazione) e trattarli in modo conforme al GDPR. Il lato privacy è spesso trascurato dai maker, ma è parte integrante della sicurezza: cookie banner a norma, informativa chiara, consenso raccolto correttamente. Non è solo rischio di multa, è fiducia.

5. Header di sicurezza HTTP

Gli header di sicurezza sono istruzioni che il server invia al browser per attivare protezioni aggiuntive. Costano poco e bloccano intere classi di attacchi. I principali:

HeaderA cosa serve
Content-Security-PolicyLimita da dove si possono caricare script e risorse, riduce l'XSS
Strict-Transport-SecurityImpone l'uso di HTTPS (HSTS)
X-Content-Type-OptionsImpedisce al browser di "indovinare" il tipo di file
X-Frame-OptionsBlocca il clickjacking (il sito incorniciato in siti malevoli)
Referrer-PolicyControlla quali informazioni vengono passate ad altri siti

Molti siti generati velocemente escono online senza nessuno di questi header: una delle mancanze più comuni e più facili da correggere.

6. Aggiornamenti, patch e dipendenze

Gran parte degli attacchi non sfrutta trucchi geniali, ma vulnerabilità già note in librerie e componenti non aggiornati. Un plugin vecchio o una dipendenza con una falla pubblica sono porte aperte segnalate a tutti. Tieni un elenco delle tue dipendenze, aggiornale con regolarità e usa strumenti che ti avvisano quando esce una vulnerabilità nota.

7. Backup e ripristino

Il backup non impedisce un attacco, ma è ciò che ti salva quando tutto il resto è fallito. Un sito web sicuro ha backup automatici, regolari e testati, conservati separati dal server principale. La domanda giusta non è "faccio i backup?" ma "quanto ci metto a rimetterli online se domani il sito sparisce?".

8. Rate limiting e protezione delle API

Il rate limiting mette un tetto al numero di richieste che un singolo utente può fare in un dato tempo. Senza, un attaccante può tentare migliaia di password al minuto, saturare il server o prosciugare il tuo budget. È essenziale su login, form e API pubbliche.

9. Gestione dei segreti e delle chiavi API

Le chiavi API, le password del database, i token di accesso sono le chiavi di casa. Non devono mai finire nel codice pubblico, nel repository su GitHub o, peggio, nel JavaScript scaricato dal browser dell'utente. Vanno tenute in variabili d'ambiente o in gestori di segreti, con permessi minimi. Una chiave esposta è uno dei problemi più gravi e frequenti, e spesso non ci si accorge finché non arriva il conto.

Le minacce più comuni, spiegate semplice

Ecco le minacce che colpiscono più spesso i siti dei maker e delle PMI.

  • Cross-Site Scripting (XSS): l'attaccante inietta codice (di solito JavaScript) in una pagina, che viene poi eseguito nel browser di altri utenti per rubare sessioni o dati. Nasce dal mostrare l'input degli utenti senza "ripulirlo". Difesa: validare ogni input e usare la Content-Security-Policy.
  • SQL Injection: comandi malevoli inseriti nei campi del sito vengono eseguiti dal database, permettendo di leggere o cancellare dati. Difesa: usare sempre query parametrizzate.
  • Dati e credenziali esposte: chiavi API nel codice, file di configurazione accessibili, endpoint troppo generosi, pannelli admin senza protezione. Spesso non serve un attacco sofisticato: basta guardare nel posto giusto. È la categoria che pesa di più nella pratica.
  • Credenziali deboli e riutilizzate: password come "admin123", account senza 2FA, credenziali riciclate da servizi già violati. Il modo più economico per entrare, senza competenze tecniche.

Il caso dei siti fatti con l'AI (vibe coding)

Costruire un sito o un'app scrivendo prompt a un assistente AI, il cosiddetto vibe coding, è ormai normale: veloce, potente, alla portata di chiunque. C'è però un problema ricorrente: l'AI ottimizza per "far funzionare la cosa", non per renderla sicura.

Il risultato è che moltissimi siti generati con l'AI escono online con le stesse falle standard: chiavi API scritte nel codice o nel frontend, endpoint che restituiscono dati senza controllare chi li chiede, nessun rate limiting su form e login, header di sicurezza assenti, cookie e privacy non a norma.

Non è colpa tua se non le conoscevi: il codice "funziona", il sito si vede, tutto sembra a posto. Il problema è che queste falle non si vedono dalla home page. Per questo esistono strumenti come Appurai, che scansionano un sito o un'app e mostrano dove sono i buchi — chiavi esposte, endpoint aperti, header mancanti, problemi GDPR — anche quando il progetto è nato interamente da prompt AI. Se hai costruito così, vale la pena approfondire i rischi specifici nella nostra guida al vibe coding.

Come rendere sicuro un sito: da dove partire

Per chi non ha un team dedicato, l'ordine sensato è questo:

  1. Fai una fotografia dello stato attuale. Prima di correggere devi sapere cosa è rotto: un test di sicurezza del sito web ti dà la lista concreta dei problemi.
  2. Chiudi le cose gravi e veloci. Chiavi esposte, endpoint senza auth, HTTPS mancante: alto impatto, bassa fatica.
  3. Aggiungi gli strati mancanti. Header di sicurezza, rate limiting, 2FA per gli admin.
  4. Metti in piedi la routine. Backup automatici, aggiornamento delle dipendenze, controlli periodici.
  5. Verifica di aver risolto davvero. Rifai il test: la guida su come verificare la sicurezza di un sito ti spiega come accertarti che le falle siano chiuse.

La sicurezza non è un progetto con una data di fine: è un'abitudine. Ma la prima scansione onesta è quella che sposta di più l'ago.

Domande frequenti

Basta l'HTTPS per avere un sito web sicuro?

No. L'HTTPS cifra la connessione ed è indispensabile, ma protegge solo i dati in transito. Un sito può avere il lucchetto verde e insieme esporre chiavi API o essere vulnerabile a SQL injection. È un pilastro, non l'intera casa.

Quanto costa rendere sicuro un sito?

Molte correzioni importanti — forzare l'HTTPS, aggiungere header, spostare le chiavi in variabili d'ambiente, attivare il rate limiting — non costano nulla in licenze, solo tempo. Il costo vero è sapere cosa correggere: per questo la scansione iniziale rende di più.

Il mio sito è piccolo, davvero può interessare a qualcuno?

Sì. La maggior parte degli attacchi è automatica: dei bot scansionano internet alla ricerca di falle note, senza curarsi di cosa sia il tuo sito. Un sito piccolo con una chiave esposta è un bersaglio come uno grande.

Un sito fatto con l'AI è meno sicuro?

Spesso, in pratica, sì. Gli assistenti AI generano codice che funziona senza necessariamente applicare le best practice di sicurezza, quindi molti progetti nati da prompt escono con falle ricorrenti. E sembra tutto a posto perché il sito si vede: è proprio questo a renderlo subdolo.

Ogni quanto va controllata la sicurezza di un sito?

Idealmente in modo continuo, e comunque a ogni modifica importante: nuove funzioni, dipendenze ed endpoint introducono nuovi rischi. Un controllo periodico automatico batte una verifica una tantum che invecchia in fretta. Se sospetti di essere già stato colpito, la priorità cambia: leggi cosa fare se il sito è stato hackerato.

In sintesi

Un sito web sicuro è il risultato di più strati che lavorano insieme, dai fondamentali come HTTPS e autenticazione fino a backup, rate limiting e gestione dei segreti. Nessuno, da solo, ti mette al riparo. La buona notizia è che non devi essere un esperto per partire: devi solo sapere dove guardare. Una scansione automatica come quella di Appurai ti mostra gratis dove sono i problemi del tuo sito, dalle chiavi esposte al GDPR, e se vuoi ti spiega passo passo come sistemarli.

Scopri quanto è sicuro il tuo sito

Analisi gratuita in pochi secondi: sicurezza, privacy e conformità.