Cours · Niveau intermédiaire

Auditer et durcir la sécurité d'un site web

Un déroulé en 5 phases pour passer au crible un site existant : repérer la surface d'attaque, vérifier les fondamentaux, corriger, puis valider et déployer sans rien casser. Pour chaque commande : ce qu'elle fait, et pourquoi elle compte vraiment côté sécurité.

5phases de travail
3familles de failles
7commandes décryptées
1checklist de fin
Écouter cet article (10 min)

Version audio générée localement (Pocket TTS, Kyutai, voix Estelle). Les exemples de code et tableaux sont à retrouver sur cette page.

L'esprit de ce cours

Sécuriser un site existant, ce n'est pas tout réécrire. C'est une démarche ordonnée : comprendre le terrain, lister ce qui est exposé, corriger en priorité ce qui fait le plus mal, et prouver que chaque correctif tient avant de le mettre en ligne.

Comment lire les commandes. Chaque commande du cours porte une étiquette : Sécurité quand elle sert directement à prouver ou durcir la sécurité, Déploiement quand elle met le correctif en ligne. Les étapes purement internes à une organisation (indexation de documentation, outils maison) ont été volontairement retirées : elles dépendent de votre contexte et ne relèvent pas de la sécurité.
00

Collecter le contexte

Avant la moindre vérification, on cadre. Sans ces réponses, un audit part dans le vide.

Cinq éléments à clarifier avant de commencer :

  • Nom du projet / site — de quoi parle-t-on exactement.
  • Stack technique — front (Cloudflare Pages, Vercel, HTML statique…), back / API (Worker, Node.js, Python, Go…), base de données (D1 SQLite, PostgreSQL, MongoDB…), authentification (JWT, cookies, OAuth, sessions…), email et sous-traitants (Resend, SendGrid…).
  • Repo local — le chemin absolu du dépôt.
  • Déploiement actuel — comment le site arrive en production (git push, wrangler deploy, CI/CD…).
  • Audit existant ? — y a-t-il déjà un rapport de sécurité quelque part.

Ne passez pas à la phase suivante tant que ces cinq points ne sont pas clairs. La surface d'attaque dépend entièrement de la stack : on ne cherche pas les mêmes choses sur du HTML statique que sur une API avec base de données.

01

Explorer & auditer

Cartographier ce qui est exposé, vérifier les fondamentaux, traquer les failles classiques.

Lister la surface d'attaque

  • Tous les endpoints API, publics comme admin.
  • Tous les formulaires : connexion, inscription, contact, newsletter…
  • Tous les fichiers statiques servis et leur configuration (_headers, CSP, CORS).
  • Toutes les intégrations tierces : OAuth, email, analytics, paiement.

Vérifier les fondamentaux

  • Headers HTTP : Content-Security-Policy, X-Frame-Options, Referrer-Policy, Strict-Transport-Security, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy.
  • Cookies d'authentification : HttpOnly, Secure, SameSite, durée de vie maîtrisée, et jamais de token sensible dans localStorage.
  • CORS : origines autorisées explicites, pas de wildcard ni d'origine par défaut.
  • Rate-limiting : présent sur tous les endpoints publics ?
  • Anti-bot : Turnstile, reCAPTCHA ou honeypot sur les formulaires ?

Traquer les failles classiques

Trois grandes familles concentrent l'essentiel des incidents :

  • Injection & exécution — XSS (innerHTML brut, template sans échappement, contenu utilisateur non assaini), injection SQL / NoSQL (requêtes paramétrées ?), injection HTML / email (un email admin construit avec du contenu utilisateur).
  • Authentification & session — CSRF (tokens sur les mutations POST/PUT/DELETE ?), JWT révocables, tokens de réinitialisation hashés, state OAuth aléatoire et signé.
  • Fuites — secrets en clair (query string, logs, localStorage, .env commité), fichiers sensibles exposés (.bak, .env, identifiants), et conformité RGPD (consentement avant analytics, politique de confidentialité factuelle).

Écrire l'audit

  • Créer un fichier daté, par exemple docs/audit-securite-AAAA-MM-JJ.md.
  • Un tableau récapitulatif : sévérité, problème, fichier(s), statut, preuve.
  • Une liste classée en HIGH / MEDIUM / LOW.
02

Planifier

Décider de l'ordre et du périmètre avant de toucher au code.

  • Les HIGH d'abord, puis MEDIUM, puis LOW.
  • Pour chaque sujet, l'approche la plus simple qui résout vraiment le problème — pas d'abstraction non demandée.
  • Si une correction touche plus de deux fichiers ou plus de trois étapes : passer en mode plan et faire valider avant d'implémenter.
  • Identifier les actions irréversibles (migration de base, suppression, changement d'authentification) et demander une confirmation explicite.
03

Implémenter

Corriger par petites touches sûres, sans introduire de nouveau risque.

  • Sauvegardes : créer une copie .bak.AAAAMMJJ-HHMMSS avant de modifier un fichier sensible.
  • Modifications chirurgicales : ne toucher que ce qui est strictement nécessaire.
  • Préférer la bibliothèque standard : éviter d'ajouter une dépendance sans justification — chaque dépendance est une surface d'attaque de plus.

À ne jamais faire — mettre un secret en query string · stocker un JWT dans localStorage · faire confiance aux entrées utilisateur · modifier un fichier hors du dossier de travail sans confirmation · déployer sans avoir commité.

04

Tester & valider

Pour chaque correction, une preuve observable. « Ça devrait marcher » n'est pas une preuve.

Les commandes ci-dessous sont à adapter à votre stack. Toutes servent un même but : démontrer qu'un correctif fonctionne et qu'il n'a rien cassé.

node --check <fichier> Sécurité
node --check chemin/vers/fichier-modifie.js

À quoi ça sert — vérifie la syntaxe d'un fichier JavaScript sans l'exécuter.

Pertinent pour la sécurité ? Oui. Un correctif de sécurité qui casse la syntaxe ne part jamais en production, ou pire, casse la page. C'est la preuve minimale, instantanée, avant tout le reste.

Lancer les tests Sécurité
# Tests du back / worker
node worker/tests/*.test.mjs

# Scripts de test dédiés
node scripts/test-*.js

À quoi ça sert — rejoue les tests existants, plus ceux que vous avez ajoutés pour la faille corrigée.

Pertinent pour la sécurité ? Oui, c'est le cœur de la preuve. Le bon réflexe : écrire d'abord un test qui échoue sur la faille (XSS qui passe, token accepté à tort), puis corriger jusqu'à ce qu'il passe. Le test devient la garantie anti-régression.

npm run build:dist Sécurité
npm run build:dist   # ou l'équivalent de votre projet

À quoi ça sert — reconstruit le front à partir des sources modifiées.

Pertinent pour la sécurité ? Oui, dès que la correction touche le front (échappement HTML, header injecté au build, CSP générée). Un build qui échoue signale que le correctif ne tient pas debout ; un build propre est le préalable à un déploiement sûr.

05

Déployer & synchroniser le repo

Mettre le correctif en ligne — et faire en sorte que le dépôt reflète exactement la production.

Les commandes wrangler ci-dessous sont propres à Cloudflare ; transposez-les à votre hébergeur. Le principe, lui, est universel.

Migrations de base de données Déploiement
wrangler d1 migrations apply <db> --remote

Action irréversible — appliquer une migration sur la base distante modifie des données réelles. À ne faire qu'après confirmation, et seulement si le correctif touche le schéma. Sinon, sautez cette étape.

Déployer l'API / le Worker Déploiement
# Vérifier / ajouter les secrets côté hébergeur avant
wrangler deploy

À quoi ça sert — met en ligne le code back contenant le correctif. Pensez à vérifier que les secrets nécessaires sont bien configurés côté plateforme (jamais dans le code).

Déployer le front Déploiement
npm run build:dist
wrangler pages deploy dist --project-name=<projet>

À quoi ça sert — reconstruit puis publie le front durci (headers, échappement, CSP).

Commiter & pousser Sécurité
git add -A
git commit -m "security: ..."
git push

Pourquoi c'est une étape de sécurité. Règle d'or : le dépôt doit refléter ce qui tourne en production. Un correctif déployé mais jamais commité, c'est une rustine qui disparaît au prochain déploiement — et une faille qui revient sans prévenir. Commitez avant ou en même temps que le déploiement.

✓

Checklist & règles d'or

À relire en fin de session pour ne rien laisser en suspens.

Checklist de fin

  • Audit à jour et complet.
  • Tous les tests passent.
  • Build propre.
  • Déploiement effectué.
  • Dépôt commité et poussé.
  • Utilisateur informé des éventuels sujets optionnels restants.

Les six règles d'or

  • Explorer avant d'affirmer — lire le code réel avant toute conclusion technique.
  • Poser une brique, ne pas casser le mur — modifications minimales.
  • Preuve observable — un test, un log ou une requête avant de dire « c'est bon ».
  • Respect de l'architecture — suivre les patterns déjà en place.
  • Pas de déploiement sans commit — le dépôt est la source de vérité.
  • Prioriser le risque réel — les failles HIGH d'abord, le confort ensuite.
C
Cours rédigé par
Claude · claude.ai
Assistant IA développé par Anthropic
Données issues de Kimi Code, via le skill Arbor de Google DeepMind