📋 Ce rapport est un exemple anonymisé illustrant le format et le niveau de détail d'un audit réel.
Le site « demo-ecommerce.fr » est fictif. Vos données ne sont jamais partagées.
Interface phpMyAdmin exposée sans authentification
→ demo-ecommerce.fr/phpmyadmin
L'interface de gestion de base de données est accessible publiquement sans aucune protection. Un attaquant peut déclencher des attaques par force brute pour accéder à la totalité de la base de données (clients, commandes, mots de passe hashés, données de paiement). Des scanners automatiques détectent et attaquent ce type d'exposition en continu.
CORRECTION RECOMMANDÉE
Bloquer /phpmyadmin dans nginx : location /phpmyadmin { deny all; } ou restreindre par IP (allow 1.2.3.4; deny all;). Si phpMyAdmin n'est pas utilisé, le désinstaller. Changer le chemin d'accès par défaut si le maintien est nécessaire.
jQuery 1.12.4 — CVE-2019-11358 · CVE-2020-11022
→ demo-ecommerce.fr/wp-includes/js/jquery/jquery.js
La version de jQuery utilisée contient des vulnérabilités XSS (Cross-Site Scripting) exploitables via des entrées utilisateur non filtrées. CVE-2019-11358 permet l'injection de propriétés dans des objets prototypes (prototype pollution). CVE-2020-11022 permet l'exécution de code arbitraire via HTML injecté dans des méthodes DOM. Score CVSS : 6.1.
CORRECTION RECOMMANDÉE
Mettre à jour jQuery vers la version 3.7.1 ou supérieure. Sous WordPress, utiliser le plugin "jQuery Updater" ou mettre à jour le thème et les plugins qui embarquent jQuery. Vérifier également les plugins tiers qui chargent leur propre version de jQuery.
En-têtes de sécurité HTTP absents
→ Headers manquants : CSP · X-Frame-Options · HSTS · X-Content-Type-Options
Sans Content-Security-Policy, des scripts malveillants peuvent être injectés dans vos pages. Sans X-Frame-Options, votre site est vulnérable au clickjacking (un attaquant charge votre site dans un iframe invisible pour voler des clics). Sans HSTS, la première connexion HTTP peut être interceptée avant la redirection HTTPS.
CORRECTION RECOMMANDÉE
Ajouter dans la config nginx :
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "default-src 'self'" always;
Énumération des utilisateurs WordPress via l'API REST
→ demo-ecommerce.fr/wp-json/wp/v2/users
L'API REST de WordPress expose la liste complète des utilisateurs, incluant leurs identifiants de connexion (login), adresses email et ID. Ces informations réduisent considérablement l'effort nécessaire pour une attaque par force brute sur wp-login.php — l'attaquant connaît déjà les logins valides.
CORRECTION RECOMMANDÉE
Dans functions.php : add_filter('rest_endpoints', function($endpoints){ if(isset($endpoints['/wp/v2/users'])) unset($endpoints['/wp/v2/users']); return $endpoints; }); Ou via un plugin de sécurité (Wordfence, iThemes Security) → désactiver "User Enumeration".
Formulaire de contact sans protection CSRF
→ demo-ecommerce.fr/contact
Le formulaire de contact accepte les requêtes POST sans vérification de token CSRF (Cross-Site Request Forgery). Un attaquant peut forcer un visiteur authentifié à soumettre ce formulaire à son insu depuis un site tiers, permettant l'envoi de messages frauduleux ou l'exécution d'actions non souhaitées.
CORRECTION RECOMMANDÉE
Implémenter des tokens CSRF dans tous les formulaires POST. Sous WordPress, utiliser wp_nonce_field('mon_formulaire') dans le template et wp_verify_nonce($_POST['_wpnonce'],'mon_formulaire') à la soumission. Vérifier aussi les formulaires de plugins tiers.
Listage de répertoires activé
→ demo-ecommerce.fr/wp-content/uploads/2023/
Le serveur web affiche le contenu des répertoires qui ne contiennent pas de fichier index.html. Un attaquant peut parcourir les fichiers uploadés, récupérer des documents confidentiels, des sauvegardes ou des fichiers de configuration exposés par erreur dans /uploads.
CORRECTION RECOMMANDÉE
Dans nginx : ajouter "autoindex off;" dans le bloc server. Dans Apache : ajouter "Options -Indexes" dans .htaccess ou dans VirtualHost. Créer un fichier index.html vide dans les répertoires sensibles comme mesure supplémentaire.
Cookies de session sans flags Secure et HttpOnly
→ Cookie : PHPSESSID, wordpress_logged_in_*
Les cookies de session ne sont pas protégés par les flags Secure (envoi uniquement via HTTPS) et HttpOnly (inaccessible via JavaScript). Un script XSS injecté dans une page pourrait voler le cookie de session d'un administrateur connecté et usurper son identité.
CORRECTION RECOMMANDÉE
Dans php.ini : session.cookie_secure=1 et session.cookie_httponly=1 et session.cookie_samesite=Lax. Dans WordPress, ajouter dans wp-config.php : define('ADMIN_COOKIE_PATH', '/'); et utiliser un plugin qui force les flags de sécurité sur les cookies.
Redirection HTTP sans HSTS préalable
→ http://demo-ecommerce.fr → https://demo-ecommerce.fr (301)
HTTPS est activé et la redirection HTTP→HTTPS fonctionne, mais sans header HSTS. La toute première requête HTTP d'un utilisateur peut être interceptée par un attaquant en position man-in-the-middle avant la redirection, ce qui permet de servir une version non chiffrée du site.
CORRECTION RECOMMANDÉE
Activer HSTS : Strict-Transport-Security: max-age=31536000; includeSubDomains dans les headers nginx/Apache. Une fois stable, soumettre le domaine à la liste HSTS Preload (hstspreload.org) pour une protection maximale sur tous les navigateurs.
Messages d'erreur PHP verbeux en production
→ demo-ecommerce.fr/panier?id=abc (erreur déclenchée)
Des erreurs PHP sont affichées directement dans les pages (notice, warning, parse error) révélant des chemins de fichiers absolus (/var/www/html/wp-content/plugins/...), des noms de tables de base de données et des versions de librairies. Ces informations facilitent la préparation d'attaques ciblées.
CORRECTION RECOMMANDÉE
Dans php.ini : display_errors=Off et log_errors=On. Dans WordPress, dans wp-config.php : define('WP_DEBUG', false); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);. Les erreurs seront journalisées dans wp-content/debug.log sans être affichées.
Version WordPress exposée via balise meta generator
→ <meta name="generator" content="WordPress 6.4.3">
La version exacte de WordPress est exposée dans le code source HTML. Cette information permet à un attaquant de cibler les CVE connus pour cette version spécifique et d'automatiser des exploits adaptés.
CORRECTION RECOMMANDÉE
Dans functions.php : remove_action('wp_head', 'wp_generator'); Masquer également la version dans le flux RSS en ajoutant : add_filter('the_generator', '__return_false');
En-tête Server révèle Apache 2.4.57
→ Header HTTP : Server: Apache/2.4.57 (Ubuntu)
La version exacte du serveur web et du système d'exploitation sont exposées dans chaque réponse HTTP. Ces informations aident un attaquant à identifier rapidement les CVE applicables à cette configuration.
CORRECTION RECOMMANDÉE
Dans la configuration Apache : ServerTokens Prod et ServerSignature Off. Cela remplace "Apache/2.4.57 (Ubuntu)" par simplement "Apache". Pour nginx : server_tokens off; dans le bloc http.
robots.txt révèle des chemins sensibles
→ demo-ecommerce.fr/robots.txt : Disallow: /phpmyadmin/, /wp-admin/
Le fichier robots.txt liste explicitement des chemins qu'il souhaite "cacher" aux moteurs de recherche. Paradoxalement, ce fichier est public et lu par les outils de reconnaissance automatique — il indique à un attaquant exactement quels chemins sensibles existent.
CORRECTION RECOMMANDÉE
Ne pas utiliser robots.txt pour masquer des paths sensibles — c'est contre-productif. Supprimer les lignes Disallow pointant vers /phpmyadmin, /wp-admin, /backup, etc. La vraie protection passe par la restriction d'accès serveur (auth, whitelist IP), pas par robots.txt.
Protocoles TLS obsolètes supportés (TLSv1.0, TLSv1.1)
→ Protocoles acceptés : TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3
Le serveur accepte des connexions via TLS 1.0 et 1.1, des protocoles abandonnés depuis 2020 par le PCI-DSS et dépréciés par tous les navigateurs majeurs. Ces versions sont vulnérables à des attaques connues (BEAST, POODLE). Le chiffrement proposé est insuffisant pour des données sensibles.
CORRECTION RECOMMANDÉE
Dans nginx : ssl_protocols TLSv1.2 TLSv1.3; (supprimer TLSv1.0 et TLSv1.1). Ajouter ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:...; pour restreindre aux suites de chiffrement sécurisées.
Certificat SSL/TLS valide — Let's Encrypt
→ Valide du 15/06/2024 au 15/09/2025 · SHA-256 · 2048 bits
Le certificat SSL est valide, correctement configuré et signé par une autorité de confiance reconnue par tous les navigateurs. La connexion entre vos visiteurs et le serveur est chiffrée. Point positif notable.
AUCUNE ACTION REQUISE
Vérifier que le renouvellement automatique (certbot renew) est bien configuré via cron ou systemd timer pour éviter toute expiration. Utiliser "certbot renew --dry-run" pour tester la configuration.