Ce qu’a trouvé l’audit de sécurité en boîte blanche d’un petit site : huit correctifs sur tarasovvitalii.com

Pourquoi un site portfolio a eu droit à une revue de sécurité

Un portfolio a l’air du type de site le plus sûr qui soit : quelques pages de réalisations et un formulaire de contact. tarasovvitalii.com, le site du fondateur de VITON13, va plus loin. Il fait tourner un chat sur VITON ID, construit sur 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 quinze sites concepts sous /demos/. Un visiteur qui se connecte pour écrire un message fait confiance à chacun de ces éléments à la fois.

Le 28 septembre 2026, VITON13 Studio a examiné le site comme il examinerait 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.

Méthode : le code source d’abord, les attaques sur une copie locale

Un audit de sécurité web en boîte blanche part de l’intérieur. Les auteurs de la revue ont lu chaque route de l’API et le code qui vérifie les jetons de connexion, 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 quinze démos.

Plutôt que de sonder le serveur en ligne, le studio a lancé les mêmes conteneurs en local, nginx et l’API avec les réglages de production, et a tenté chaque attaque sur cette copie. Le site en ligne et ses visiteurs restent ainsi en dehors de l’expérience, et la même requête peut être rejouée avant et après un correctif pour prouver le changement. Seul le résultat final, c’est-à-dire les en-têtes et les redirections, a été revérifié sur l’adresse en ligne.

Chaque constat confirmé a ensuite reçu un niveau de gravité. Élevé signifiait qu’une personne extérieure pouvait agir dans la session de quelqu’un d’autre ou atteindre des données privées ; moyen, qu’il manquait une couche de défense capable de transformer un petit bug en gros problème ; faible, une faiblesse qui exige des conditions inhabituelles ou ne laisse fuir que peu de choses. La liste ci-dessous suit cet ordre, et chaque élément consigne ce que faisait l’attaque avant le correctif et ce que fait la même requête après.

Le constat à risque élevé : une injection de script via une démo

Le problème le plus grave ne se trouvait pas dans le portfolio lui-même, mais dans l’une de ses démos. Le concept de boutique Oriva lisait le paramètre ?cat= dans l’adresse et l’insérait dans la page sous forme de HTML. Un lien forgé pouvait donc exécuter du script sur tarasovvitalii.com. L’OWASP décrit cette classe de bug, le cross-site scripting, comme l’injection de script dans un site auquel la victime fait confiance, et c’est exactement ce qui la rendait dangereuse ici.

Les démos partagent l’origine du chat, et le chat conserve sa session Firebase dans le navigateur, sur cette même origine. Un seul clic du propriétaire du site sur un tel lien aurait pu exposer la boîte de réception et le compte propriétaire. Une fois le bug trouvé, la correction est simple : la démo n’accepte plus que des valeurs de catégorie et de tri connues, et ignore tout le reste. Les quatorze autres démos ont été vérifiées pour le même schéma ; elles se contentent de comparer les paramètres d’adresse à des valeurs fixes.

Une politique de sécurité et des scripts épinglés pour les démos

Le constat à risque moyen concernait la défense en profondeur. La section /demos/ n’envoyait aucune Content-Security-Policy, l’en-tête qui indique au navigateur depuis quelles sources une page peut charger des scripts, des styles et des données. De plus, 52 pages de démo chargeaient Leaflet, une bibliothèque de cartes, depuis un CDN public sans empreinte d’intégrité. Si ce CDN était un jour compromis, ou si un script quelconque était injecté, rien ne limiterait ce qu’il pourrait atteindre.

Désormais, /demos/ a sa propre politique : des requêtes uniquement vers le site lui-même, des scripts uniquement depuis le site et la bibliothèque épinglée, aucun plugin. Leaflet est épinglé avec des empreintes Subresource Integrity, si bien que le navigateur refuse le fichier dès qu’un seul octet change. Dans Chrome en mode headless, les 119 pages de démo se sont chargées sous la nouvelle politique sans aucune violation.

Une injection d’en-tête dans une redirection du serveur

La règle nginx qui redirigeait /demos/<id> vers /demos/<id>/ renvoyait le chemin décodé dans l’en-tête Location. Un lien contenant %0d%0a, le saut de ligne encodé, pouvait donc ajouter son propre en-tête à la réponse, par exemple Set-Cookie. L’OWASP range ce cas dans l’injection CRLF : un retour chariot et un saut de ligne glissés à un endroit où le serveur construit des en-têtes.

La redirection n’accepte plus que des lettres, des chiffres, des traits d’union et des tirets bas, et construit elle-même l’adresse cible. La requête qui renvoyait auparavant un 301 avec un cookie injecté reçoit désormais un simple 404, aussi bien sur la copie locale que sur le site en ligne.

Cinq correctifs mineurs : messagerie, limites et serveur

Trois constats faibles concernaient le système de messages. Une adresse e-mail comme me@x.com?bcc=…&body=… passait la validation, si bien que le lien « Répondre » de la boîte de réception du propriétaire pouvait s’ouvrir avec un destinataire en copie cachée et un texte prérempli ; ces adresses sont désormais refusées, et chaque adresse d’un lien mailto: est encodée. Les noms pouvaient contenir des caractères de forçage du sens d’écriture qui déguisent le texte ; ils sont retirés. Les limites ne s’appliquaient que par adresse IP, si bien qu’en faisant tourner les adresses on pouvait remplir le disque ; un plafond quotidien global de 500 envois enregistrés s’y ajoute désormais.

Le reste relevait des réglages du serveur. L’API de messages tournait en root avec un système de fichiers accessible en écriture ; elle tourne désormais sous un utilisateur non privilégié, sur un système de fichiers en lecture seule, avec toutes les capacités Linux retirées. Chaque réponse affichait la version exacte de nginx, issue d’une branche qui ne reçoit plus de correctifs ; la version est masquée et le conteneur utilise la branche stable actuelle. HSTS, l’en-tête qui maintient les navigateurs en HTTPS, était envoyé sur le domaine principal mais pas sur www ; il couvre désormais www et les sous-domaines.

Parties du site qui ont passé la revue sans changement

Un audit qui ne liste que des problèmes cache la moitié de sa valeur. La revue a aussi confirmé ce qui était déjà bien fait : la vérification des jetons de connexion n’accepte que RS256, exige un identifiant de clé et contrôle l’audience, l’émetteur et l’expiration ; les règles Firestore ne laissent personne lire la conversation d’autrui ni écrire au nom du propriétaire ; les modèles d’e-mail échappent chaque valeur ; les journaux ne contiennent ni jetons, ni adresses e-mail, ni adresses IP ; et le chat n’insère jamais le texte d’un visiteur sous forme de HTML.

Après les correctifs, la suite de tests de l’API passe à 48 sur 48, nouvelles règles comprises, et npm audit ne signale aucune vulnérabilité connue dans les dépendances du site ou de l’API.

Le même jour, sur l’adresse en ligne, les en-têtes de réponse ont été vérifiés une fois de plus : aucune version de serveur dans aucune réponse, HSTS avec sous-domaines à la fois sur le domaine nu et sur www, la politique des démos sur /demos/, et la requête d’injection d’en-tête qui reçoit un simple 404. Le catalogue Oriva du site en ligne compare désormais la catégorie à sa liste fixe avant de l’utiliser, et la bibliothèque de cartes se charge avec ses empreintes d’intégrité.

Un audit mené par le studio du site : ses limites

Il s’agit du site du studio, examiné par le studio lui-même. Ce n’est ni un test d’intrusion indépendant ni une certification, et la revue couvre le code tel qu’il se présentait au 28 septembre 2026. Du nouveau code, de nouvelles dépendances ou une nouvelle démo exigent de refaire la même revue : c’est pourquoi un contrôle de sécurité a sa place dans un processus de mise en production plutôt que dans un projet ponctuel.

Un risque structurel demeure, par choix : les démos partagent toujours l’origine du site. La nouvelle politique limite ce que du code injecté pourrait atteindre, mais seul le déplacement des démos vers un domaine séparé les isolerait complètement. Pour une petite entreprise, la leçon est concrète : la ligne de code la plus dangereuse se trouve souvent dans la page annexe oubliée, et non dans le formulaire de connexion.