Audit de sécurité de tarasovvitalii.com : huit constats, huit correctifs

tarasovvitalii.com ne se résume pas à des pages statiques. Le site fait tourner un chat sur VITON ID (Firebase Authentication et Firestore), une petite API Node qui enregistre les messages de contact et envoie des e-mails, un serveur nginx dans Docker et des copies de 15 sites concepts sous /demos/. Un visiteur qui se connecte pour écrire au fondateur fait confiance à tout cela ; le 28 septembre 2026, nous avons donc examiné le site de l’intérieur, comme nous examinerions le site d’un client avant son lancement.

Pour chaque élément, la question était celle d’un attaquant : que peut en faire quelqu’un de l’extérieur, et combien cela coûterait-il au propriétaire ? Un constat ne comptait qu’une fois reproduit, et un correctif qu’une fois que la même attaque avait échoué contre lui.

La revue a couvert chaque route de l’API et la vérification des jetons, les règles Firestore avec leurs 39 tests dans l’émulateur, la configuration nginx et Docker Compose, les dépendances npm du site et de l’API, l’interface du chat et le code des 15 démos. Plutôt que de sonder le serveur en ligne, nous avons lancé les mêmes conteneurs en local, nginx et l’API avec les réglages de production, et tenté chaque attaque sur cette copie.

Le constat le plus grave se trouvait dans une démo, pas dans le site lui-même. Le concept de boutique Oriva insérait le paramètre d’adresse ?cat= dans la page sous forme de HTML : un lien forgé exécutait donc du script sur tarasovvitalii.com, l’origine où le chat conserve sa session Firebase, et un seul clic du propriétaire aurait pu exposer sa boîte de réception. Les 14 autres démos se contentent de comparer les paramètres d’adresse à des valeurs connues.

Les correctifs, constat par constat. La démo Oriva n’accepte plus que des catégories et des ordres de tri connus. /demos/ a sa propre Content-Security-Policy, et Leaflet, la bibliothèque de cartes que 52 pages de démo chargent depuis un CDN, est épinglée avec des empreintes d’intégrité. La redirection /demos/<id> est reconstruite à partir d’un motif strict au lieu de renvoyer le chemin demandé tel quel. Les adresses e-mail qui pourraient glisser une copie cachée (BCC) ou du texte dans les liens « Répondre » du propriétaire sont refusées, et les caractères de forçage du sens d’écriture sont retirés des noms.

Le serveur a reçu le reste : un plafond quotidien global des envois enregistrés (500 par défaut) en plus des limites par adresse ; l’API de messages qui tourne sous un utilisateur non privilégié, sur un système de fichiers en lecture seule, avec toutes les capacités Linux retirées ; la version de nginx masquée dans les réponses, sur la branche stable actuelle ; et HSTS, l’en-tête qui maintient les navigateurs en HTTPS, envoyé aussi sur www et étendu aux sous-domaines. De nouveaux tests de l’API couvrent les adresses refusées, les caractères retirés et le plafond.

Huit constats, huit corrigés : un à risque élevé, un moyen et six faibles. La charge utile qui s’exécutait sur l’ancien code de la démo ne fait plus rien sur le nouveau, et la requête qui injectait un en-tête Set-Cookie reçoit désormais un simple 404. Les 119 pages de démo se chargent sous la nouvelle politique sans aucune violation, les tests de l’API passent à 48 sur 48 avec les nouvelles règles couvertes, et npm audit ne signale aucune vulnérabilité connue dans les dépendances du site ou de l’API.

Vérifié et jugé solide : la vérification des jetons d’identification Firebase (RS256 uniquement, identifiant de clé obligatoire, audience, émetteur et expiration contrôlés), des règles Firestore qui ne laissent personne lire la conversation d’autrui ni écrire au nom du propriétaire, des modèles d’e-mail qui échappent chaque valeur, des journaux sans jetons, sans adresses e-mail ni adresses IP, et un chat qui n’insère jamais le texte d’un visiteur sous forme de HTML. Sur le site en ligne, le 28 septembre 2026, les en-têtes de réponse n’affichent aucune version de serveur, HSTS avec sous-domaines est présent sur les deux adresses et la politique des démos sur /demos/, et la requête d’injection d’en-tête reçoit un 404.

C’est notre propre site, pas un travail pour un client. La revue a été menée par le studio à partir du code source ; ce n’est ni un test d’intrusion indépendant ni une certification. Les attaques ont été tentées sur une copie locale des conteneurs de production, pas contre le serveur en ligne ; seuls les en-têtes de réponse et la redirection ont été revérifiés sur l’adresse en ligne.

Le résultat couvre ce que nous avons vérifié le 28 septembre 2026 : du nouveau code, de nouvelles dépendances ou de nouvelles démos demandent la même revue. Les démos partagent toujours l’origine du site ; la nouvelle politique limite donc ce que du code injecté pourrait atteindre, sans l’isoler. Déplacer les démos sur un domaine à part les isolerait complètement.

Comment vérifier le portfolio d’une agence web →