Sécurité et données personnelles
Ce que l'outil fait par défaut : hachage, limites de tentatives, chiffrement au repos, privilèges, journal d'audit et durées de conservation appliquées.
Un site livré devient la responsabilité de celui qui le tient. Ce qui suit n'est donc pas une liste d'options à activer : c'est ce que l'outil fait par défaut, sans réglage à trouver.
Les comptes, les accès, les données
- Les mots de passe sont hachés par l'algorithme que le framework juge le meilleur au moment où ils sont posés, pas par un choix figé dans un fichier qui vieillit.
- Cinq tentatives de connexion ratées par quart d'heure, sur l'administration comme sur l'espace personnel du site public.
- Une adresse e-mail se vérifie, un mot de passe se réinitialise par un lien qui expire.
- Des privilèges par écran et par action : le menu latéral ne montre que ce qui est ouvert au compte.
- Cent vingt-sept actions journalisées dans les huit modules : qui a fait quoi, sur quel objet, et quand.
- Les notes et le tracé d'une signature sont chiffrés en base, et pas seulement gardés derrière un mot de passe.
- Le contenu riche est nettoyé à l'enregistrement, puis une seconde fois avant d'atteindre le navigateur.
- Dix envois de formulaire par heure et par adresse : un formulaire public n'est pas une porte ouverte.
- Supprimer une publication passe par la corbeille, et la corbeille se purge à date.
Ce qui est écrit noir sur blanc
- La page qui collecte dit ce qu'elle collecte, sur quelle base, pour combien de temps, et qui en répond.
- Les durées de conservation sont des réglages que le code applique : une durée échue autorise une suppression, elle ne la déclenche pas.
- Les services extérieurs se branchent avec le compte du client, jamais le mien, et sont éteints par défaut.
- Les données restent chez le client : son serveur, son nom de domaine, ses comptes.
Rien de tout cela ne remplace une sauvegarde. C'est la première chose posée avant une mise en ligne, et la seule qui compte le jour où le reste a échoué.