Pourquoi ce site n'a ni cookie ni traceurbrouillon
Ouvrez un site au hasard avec les outils de développement du navigateur : avant même d’avoir lu une ligne, votre navigateur a souvent parlé à une dizaine de serveurs qui ne sont pas celui que vous visitez. Polices, statistiques, vidéos, boutons de partage : chacun apprend que vous êtes passé. Ici, votre navigateur ne parle qu’à un seul serveur, celui du site. Ce n’est pas une promesse, c’est une règle que le navigateur applique lui-même.
Concrètement, ce site ne dépose aucun cookie, d’où l’absence de bandeau : il n’y a rien à accepter. Il ne mesure pas l’audience ; je ne sais ni combien vous êtes, ni d’où vous venez. Les polices sont servies depuis le site, aucune bibliothèque ne vient d’un CDN, aucune vidéo n’est intégrée, et il n’y a aucun formulaire. Une seule chose est mémorisée dans votre navigateur, et seulement si vous la demandez : votre choix entre le thème clair et le thème sombre. Elle n’est jamais transmise.
Empêcher une page de charger ce qu’elle ne devrait pas
Tout commence par un choix d’architecture : le site est statique. Les pages sont générées à l’avance à partir de fichiers de texte, et le serveur se contente de distribuer des fichiers. Pas de base de données, pas de compte, pas de code exécuté à chaque visite : il n’y a presque rien à attaquer, et rien à collecter.
Reste le navigateur, qui chargera volontiers tout ce qu’une page lui demande. Chaque page arrive donc avec un en-tête qui lui dit ce qu’il a le droit de charger :
Content-Security-Policy:
default-src 'self'; script-src 'self'; style-src 'self';
img-src 'self' data:; object-src 'none';
base-uri 'none'; frame-ancestors 'none';
form-action 'none''self' veut dire : ce site, et rien d’autre. Un script venu d’ailleurs, ou injecté dans la
page, serait refusé par le navigateur lui-même. Même un script écrit directement dans le
HTML est interdit : tout le code doit vivre dans des fichiers à part.
Une règle qui n’est vérifiée qu’à la main finit toujours par être oubliée. À chaque construction du site, un script relit donc toutes les pages produites et refuse la publication s’il y trouve un script ou un style écrit dans la page, une ressource venue d’un autre domaine ou une adresse e-mail en clair :
# Extrait du contrôle lancé après chaque build
grep -nE '<style[\s>]' $html_files && report "balise <style> (bloquée par la CSP)"
grep -noE '(src|srcset)="(https?:)?//[^"]+"' $html_files && report "ressource tierce (src)"L’adresse de contact suit la même logique. Elle est encodée dans la page et ne se reconstitue que lorsque vous cliquez sur « Afficher l’adresse » ; les robots qui moissonnent les adresses pour le spam lisent le texte brut, et repartent bredouilles.
Renoncer aux statistiques, et à quelques facilités
Cette rigueur a un prix. Je ne saurai pas quel article a été lu : si un texte vous a été utile, le seul moyen de me le dire, c’est de m’écrire. Certains outils ont aussi dû être remplacés. Celui qui colore le code par défaut écrit un style sur chaque mot, directement dans la page, ce que la politique de sécurité refuse ; il a fallu en choisir un autre, qui passe par des classes. Et le jour où une vidéo sera utile, elle restera derrière un bouton « cliquer pour charger » : c’est vous qui déciderez de contacter le serveur de la plateforme.
Protéger le lecteur, le site et la conformité d’un même geste
Ce que ça protège, c’est d’abord vous : votre visite ne nourrit le profil publicitaire de personne. C’est ensuite le site : moins il y a de pièces mobiles, moins il y a de portes, et un site qui n’exécute aucun code à chaque visite ni n’accepte de ressource extérieure ne se pirate pas comme un CMS mal mis à jour. C’est enfin la conformité, presque par construction : sans cookie ni traceur, l’article 82 de la loi Informatique et Libertés n’a rien à demander à ce site, et la page de confidentialité tient en quelques lignes vraies.
Le reste du chemin, le passage sur un serveur dédié et durci, et ce que « durci » veut dire en pratique, fera l’objet d’un prochain billet.