Pourquoi chaque relance nécessite un audit de sécurité – Leçons tirées de 50 projets web

Plus de 50 projets web – chaque audit post-lancement a révélé des failles. Accès administratifs ouverts, serveurs de staging oubliés, mots de passe par défaut. Une relance sans vérification de sécurité est du russe roulette.

L’essentiel

87 % des relances sont lancées sans revue de sécurité
Top 3 : accès staging, identifiants par défaut, redirections HTTPS manquantes
Vérification pré-lancement : 2-4 heures, fraction du temps de réparation des dommages
Les scanners trouvent 60 % – les 40 % critiques nécessitent une vérification manuelle

Le piège de la relance

Liste de contrôle le jour du lancement : redirections, DNS, analytics. Ce qui manque : désactiver le staging, révoquer les accès de développement, désactiver le débogage, en-têtes de sécurité.

Failles les plus fréquentes

Staging : staging.example.com reste en ligne – mots de passe faibles, sans WAF.

Identifiants : admin/admin, clés API dans le JS, mots de passe de base de données dans les fichiers de configuration.

Contenu mixte : HTTP sur HTTPS permet les attaques MITM.

Conclusion

Deux heures de vérification économisent des mois de travail ultérieur. La liste de contrôle est simple – la discipline est difficile.

Faits clés

Exposition staging : 18 % des sites web accessibles via des sous-domaines oubliés (Detectify).

Temps d’exploitation : 15 minutes après la découverte, les scanners trouvent de nouvelles failles.

Questions fréquentes

Un scanner suffit-il ?

Pour les bases. La logique métier nécessite une vérification manuelle.

Qui vérifie ?

Idéalement, quelqu’un en dehors du projet.

Coûts ?

2 000 à 8 000 euros. Toujours moins cher que l’alternative.

À propos de l'auteur: Tobias Massow

Plus d'articles de Tobias Massow

Aussi disponible en

Español English Deutsch