Cookie, form e password condivisa: il lato noioso del sito che nessuno vuole sentire (e poi paga)
Perché il banner cookie ‘finto’, il modulo contatti che finisce chissà dove e l’account admin unico sono problemi veri, e come li affronto in progetto senza farti leggere un manuale da avvocato.
Sono Matteo Santoro. Nel lavoro quotidiano su siti ed e-commerce la parte che fa storcere il naso non è il CSS: è quando ti chiedo dove finiscono i messaggi del form, se quel pixel lo avete autorizzato davvero o perché cinque persone condividono la stessa password del pannello.
Non sto qui a fare il legale: se ti serve un parere su GDPR o clausole contrattuali, il professionista giusto non sono io. Quello che posso dirti con cognizione di causa è cosa succede nel codice quando queste cose non sono chiare, perché il risultato non è “un dettaglio burocratico”, è sit offline, dati sparsi, clienti che non riescono a compilare un campo o banner dei cookie che sembrano seri ma sotto non bloccano nulla.
Il sito dice una cosa, gli script ne fanno un’altra
Succede spesso: in pagina privacy c’è scritto che usate “solo cookie tecnici”, ma in homepage partono analytics, mappe, chat, remarketing. Non è un problema solo di testo: è che qualcuno ha aggiunto uno strumento “tanto per vedere i numeri” e nessuno l’ha riallineato al resto.
Io in fase di Siti web preferisco sapere subito l’elenco delle integrazioni (anche quelle che “magari mettiamo dopo”). Così non costruisco un flusso che poi va smontato perché il consulente legale ti ferma a go-live, o perché il fornitore ads chiede un evento che non hai mai tracciato bene.
Il form “contattaci” non è innocuo
Il classico modulo con nome, email e messaggio sembra banale. Poi scopri che:
- i messaggi finiscono in una casella condivisa da tre reparti e nessuno sa chi risponde;
- oppure partono verso uno Zapier / Make / CRM che qualcuno ha collegato un martedì pomeriggio senza documentarlo;
- oppure restano per anni in un database che nessuno pulisce.
Non sto dicendo che sia illegale per forza: dico che è fragile. E fragile, nel web, prima o dopo si rompe (cambio personale, cambio fornitore, audit, incident di sicurezza).
Se integri chatbot o IA, il discorso si amplifica: una conversazione non è “testo anonimo”, è spesso dato personale che attraversa server di terzi. Per il lato implementativo ho già messo nero su bianco una checklist su chatbot e IA.
Sicurezza: le cose noiose che funzionano
Niente da film: niente hacker in felpa che battono a raffica.
- HTTPS serio, certificati che non scadono nel silenzio, niente dati sensibili finiti per sbaglio nell’URL.
- Account con nome e cognome (o ruolo), 2FA dove si può, e addio al mitico admin / Admin123! passato in chat aziendale da tre anni.
- Aggiornamenti e backup che non sono teoria: se non li tratti come abitudine, il sito diventa quello che descrivevo nel pezzo sulla manutenzione, cioè qualcosa che regge fino a quando non regge più.
La sicurezza “aggiunta alla fine” è sempre la peggiore: patch sopra patch, plugin che si pestano i piedi, e tu che paghi lo stesso sito due volte.
Accessibilità: non è filosofia, è traffico (e mercato)
Qui mi limito a rimandarti al pezzo sull’e-commerce lento o non accessibile: il punto non è fare la morale, è che barriere invisibili chiudono porte a persone reali e, in molti contesti UE, ti mettono anche in una posizione scomoda rispetto alle regole del mercato.
In progetto preferisco che non sia una riga scritta piccola in fondo al preventivo: “se avanza tempo facciamo accessibile”. O è un obiettivo, o non lo è.
Cosa ti chiedo io, in pratica
Niente quiz da quindici pagine. Mi basta che tu sappia (o che andiamo a scoprire insieme): quali strumenti girano sul sito, chi deve ricevere i lead, quanto tempo tenete i dati, se vendete solo in Italia o anche altrove. Il resto lo traduco in scelte tecniche coerenti.
Se stai lanciando qualcosa di nuovo o vuoi una passata di sanity check su un sito già online, guarda il servizio Siti web e scrivimi dai contatti: partiamo dal concreto, non dal PowerPoint.

