Ce que nous protégeons, et ce que nous ne protégeons pas encore

Ce que nous protégeons

• Les comptes des agences : adresse électronique, nom, mot de passe, clés d'API.
• Les sites surveillés et leurs résultats d'audit. Les sites sont publics, mais la liste de ceux qu'une agence suit est une donnée commerciale : un concurrent y lirait qui sont ses clients.
• Le serveur lui-même. Le scanner ouvre, avec un vrai navigateur, des pages que nous ne contrôlons pas. C'est le point le plus exposé, et celui qui a reçu le plus d'attention.

Comptes et sessions

• Mots de passe : douze caractères au moins, conservés sous forme d'empreinte (scrypt, avec un sel propre à chaque compte). Nous ne pouvons pas les lire, et une fuite de la base ne les livrerait pas.
• Connexion : dix tentatives par minute et par adresse électronique, trente par minute et par adresse IP. Un compte inconnu et un mauvais mot de passe reçoivent la même réponse dans le même temps. La connexion et le mot de passe oublié répondent la même chose que l'adresse soit inscrite ou non.
• Session : un jeton signé, dans un cookie que le navigateur ne laisse pas lire aux scripts, transmis en https seulement, valable trente jours.
• Changer d'adresse ou de mot de passe exige le mot de passe courant : une session laissée ouverte sur un poste partagé ne permet pas de s'approprier le compte.
• Mot de passe oublié : un lien à usage unique, valable une heure, dont la base ne garde qu'une empreinte. La réponse est la même que l'adresse soit inscrite ou non. Trois envois par heure et par adresse.
• Adresse électronique : à confirmer par un lien valable vingt-quatre heures. Tant qu'elle ne l'est pas, le service ne lui envoie rien d'autre : on peut s'inscrire avec l'adresse de quelqu'un, pas lui faire recevoir nos alertes.
• Clés d'API : la base ne garde que l'empreinte de la clé et ses huit derniers caractères, pour que vous reconnaissiez la vôtre. Une base qui fuit ne livre aucune clé utilisable.
• Rôle administrateur : attribué à la main sur le serveur, jamais par l'application. Aucune page, aucune route ne permet de le prendre. Le compte de démonstration montré aux prospects n'est pas administrateur.
• Chaque requête vérifie que ce qu'elle touche — site, scan, clé — appartient bien au compte connecté. Un identifiant deviné ne rend rien. Les requêtes qui modifient quelque chose doivent venir de notre propre site : une page tierce ne peut pas les forger à votre insu.

Le scanner et les sites tiers

« Auditer mon site » ne doit jamais devenir « faire visiter notre réseau interne par le scanner ». Chaque adresse soumise est jugée deux fois : à la saisie, sur sa forme (http ou https seulement, ports usuels, pas d'identifiants dans l'adresse), puis juste avant la connexion, sur ce que le nom de domaine désigne réellement. Une adresse qui mène à un réseau privé, à la machine elle-même ou aux services internes d'un hébergeur est refusée. Les redirections sont suivies une à une, cinq au plus, et chaque étape est jugée de la même façon. Cela vaut pour la page auditée, chaque page de l'échantillon, la page accessibilité, les documents PDF, le fichier robots.txt, le plan du site, et l'adresse de webhook que vous saisissez.

Le navigateur du scanner tourne sous un compte sans privilège, dans un conteneur qui ne peut rien élever ni monter, et qui ne voit que la base de données et la file d'attente : une page malveillante qui prendrait la main sur le navigateur ne trouverait rien d'autre.

Le scanner s'annonce sous son nom, respecte robots.txt, ne soumet aucun formulaire, ne saisit aucun mot de passe et n'ouvre que le nombre de pages du plan. Un responsable de site qui nous voit passer dans ses journaux trouve tout cela, et comment nous exclure, sur la page à propos du scanner.

Le diagnostic gratuit, ouvert sans compte, est la porte la plus facile à pousser pour occuper le serveur. Il est borné : trois demandes par minute et par adresse, vingt par heure pour tout le monde, et une file séparée de celle des clients — une file de diagnostics pleine ne retarde pas d'une seconde le scan d'un abonné.

Hébergement et sauvegardes

• Serveur en France, chez OVH à Gravelines. La base de données et la file d'attente n'écoutent que sur le réseau interne du serveur : rien n'est joignable depuis l'extérieur en dehors du site lui-même, servi en https avec des certificats renouvelés automatiquement.
• En-têtes de sécurité : politique de sécurité du contenu, HSTS un an, aucune inclusion du site dans un cadre tiers.
• Sauvegarde quotidienne de la base, conservée trente jours sur le serveur, restauration testée dans une base d'essai. OVH conserve en plus une image quotidienne du serveur.
• Copie chiffrée hors OVH, en cours d'activation : la sauvegarde du jour part chaque nuit vers un stockage objet chez Scaleway à Paris, chiffrée sur le serveur avant d'en sortir — contenu et noms de fichiers. Scaleway ne voit que des blocs opaques. La clé donnée au serveur ne sait pas supprimer : qui prendrait le serveur pourrait lire ces sauvegardes, pas les faire disparaître. La copie distante est conservée quatre-vingt-dix jours. Le mécanisme est écrit et testé de bout en bout ; il s'active dès que le compte de stockage est ouvert, et cette page le dira.
• Surveillance : un service extérieur attend un signal régulier du serveur et de la sauvegarde ; c'est l'absence de signal — machine morte, réseau coupé — qui déclenche l'alerte, ce qu'un script sur la machine ne peut pas faire.
• Ce qui sort du serveur : dans les courriels et les rapports exportés, tout ce qui vient d'un site audité ou d'un utilisateur — nom de site, titre de page, extrait de code — est échappé avant d'entrer dans le document.
• Dépendances : l'audit des bibliothèques utilisées ne signalait rien au 17 septembre 2026. Il est relancé à chaque mise à jour, et au moins une fois par mois.

Rapports partagés

Un rapport peut être partagé par un lien de la forme /rapport/[jeton]. Ce qu'il faut savoir avant d'en envoyer un :

• Qui le voit : quiconque a le lien. Il n'y a ni compte ni mot de passe ; le jeton (43 caractères aléatoires) est la seule protection. Transféré, il donne le même accès.
• Ce qu'il montre : le nom et l'adresse du site, la date, le taux de conformité et la grille des 106 critères, les obligations du décret et leurs remèdes, les dix règles les plus fréquentes, la liste des pages analysées. Ce qu'il ne montre pas : ni sélecteur CSS, ni extrait de code, ni correction détaillée.
• Durée : trente jours, puis le lien ne répond plus. Son auteur peut le révoquer avant, depuis le rapport ; l'effet est immédiat.
• Indexation : la page porte noindex, nofollow en en-tête HTTP et dans le balisage ; elle n'est pas mise en cache. Le lien reste toutefois dans l'historique du navigateur de chaque lecteur, et dans le courriel qui l'a transmis.
• Consultations : l'auteur voit combien de fois le lien a été ouvert, la première et la dernière fois. Aucune adresse IP n'est conservée.

Limites connues

Ce qui n'est pas corrigé, listé pour qu'on ne l'oublie pas et pour que vous n'ayez pas à le découvrir.

• Redirection DNS tardive. Un domaine qui répond une adresse publique à notre vérification puis une adresse privée au navigateur quelques millisecondes plus tard n'est pas détecté. Le conteneur sans privilège et le réseau interne réduit limitent ce qu'un tel accès donnerait : la base et la file d'attente, protégées par mot de passe, et rien d'autre.
• Scripts en ligne. La politique de sécurité du contenu autorise encore les scripts et styles écrits dans la page, parce que le cadre technique du site en injecte. Le passage à une politique stricte est prévu ; il est sans urgence tant que le site n'affiche aucun contenu tiers sans l'échapper.
• Webhooks non signés. Le destinataire d'un webhook ne peut pas vérifier que l'appel vient de nous. La charge ne contient que des scores, rien qu'on ne puisse lire sur le tableau de bord.
• Épuisement du diagnostic gratuit. Qui épuise les vingt diagnostics de l'heure prive tout le monde du diagnostic pendant une heure. C'est voulu : mieux vaut « réessayez dans une heure » qu'un serveur à genoux. Les comptes abonnés ne sont pas touchés.
• Les secrets de sauvegarde sont sur le serveur. Il le faut pour que la copie chiffrée soit automatique. Elle protège contre la perte — disque, incendie, compte d'hébergement fermé, erreur de manipulation — et contre l'effacement depuis le serveur, pas contre le vol du serveur lui-même.
• L'inscription révèle une adresse. Le formulaire d'inscription indique qu'une adresse est déjà utilisée (dix essais par minute et par adresse IP).
• Cadence de visite par analyse, pas par site. Deux analyses simultanées du même site vont deux fois plus vite que ce que robots.txt demande.
• Un seul serveur. Le site, le scanner et la base sont sur la même machine. Une panne l'arrête entier, le temps de restaurer ailleurs depuis la sauvegarde.

Signaler une faille

Écrivez à cesar.guinot66@gmail.com avec « sécurité » dans l'objet. Nous répondons sous deux jours ouvrés, et nous ne poursuivons pas quelqu'un qui signale de bonne foi. La même adresse figure dans notre fichier security.txt, au format que les chercheurs consultent en premier.