Scanner les vulnérabilités d'un site sans payer : outils open source

Payer un pentest à 5 000 € est utile une fois par an pour un site critique. Pour le reste du temps, une poignée d'outils open source suffit à repérer 80 % des failles évidentes : plugins WordPress vulnérables, headers manquants, TLS mal configuré, secrets dans un repo Git, image Docker truffée de CVE. Cette doc est la checklist des scanners qu'on utilise en interne chez Datacampus, avec les commandes qui marchent sur une Debian à jour.

Pourquoi scanner régulièrement

• Les CVE publiées chaque semaine touchent WordPress, ses plugins, les runtimes PHP, les images Docker courantes. Ce qui était sain hier ne l'est plus aujourd'hui.
• Un attaquant qui cible une cible facile lance d'abord les mêmes scanners. Si vous voyez ce qu'il voit, vous le prenez de vitesse.
• Intégrer un scan dans la CI coûte 2 minutes par pipeline et rattrape des oublis humains (clé AWS committée, image de base obsolète, header CSP supprimé par erreur).

1. WPScan — spécifique WordPress

Le scanner de référence pour WordPress. Interroge la WPVulnDB (base CVE communautaire) et détecte : version du core, plugins installés et leurs CVE connues, thèmes vulnérables, utilisateurs énumérables, fichiers de config exposés.

# Installation (Ruby requis)
sudo apt install -y ruby ruby-dev build-essential libcurl4-openssl-dev
sudo gem install wpscan

# Scan standard
wpscan --url https://exemple.fr --enumerate vp,vt,u

# Avec token API (500 requêtes/jour gratuites, inscription sur wpscan.com)
wpscan --url https://exemple.fr --api-token VOTRE_TOKEN \
       --enumerate vp,vt,u,dbe --plugins-detection aggressive

Les flags utiles :

• vp : vulnerable plugins (plugins avec CVE publiées).
• vt : vulnerable themes.
• u : énumération des users (révèle les logins, utile pour brute force).
• ap : all plugins (détecte même les plugins à jour, génère beaucoup de requêtes).

Sans token API, vous voyez les plugins mais pas les détails des CVE. Avec token, chaque plugin détecté est accompagné de son identifiant CVE et de la version corrigée.

2. Nikto — scanner web générique

Le vétéran. Moins fin que nuclei mais imbattable pour détecter les fichiers et dossiers exposés par erreur : /.git/, /config.bak, /phpinfo.php, /adminer.php, /.env, méthodes HTTP dangereuses (PUT, DELETE activés), bannières serveur qui fuitent, headers manquants.

# Installation
sudo apt install -y nikto

# Scan simple
nikto -h https://exemple.fr

# Avec output dans un fichier
nikto -h https://exemple.fr -o rapport-nikto.html -Format html

# Scan ciblé sur un path
nikto -h https://exemple.fr -root /wp-admin/

Nikto est bruyant (plusieurs milliers de requêtes), il déclenchera les WAF et laissera des traces dans les logs. À lancer en accord avec l'hébergeur si le site est en prod.

3. nuclei — le scanner moderne

Outil Go, basé sur des milliers de templates YAML maintenus par la communauté (ProjectDiscovery). Chaque template cible une CVE précise, un panel admin exposé, une erreur de config typique. C'est devenu le standard pour le scan rapide et ciblé.

# Installation via binaire
wget https://github.com/projectdiscovery/nuclei/releases/latest/download/nuclei_linux_amd64.zip
unzip nuclei_linux_amd64.zip
sudo mv nuclei /usr/local/bin/

# Première mise à jour des templates
nuclei -update-templates

# Scan standard
nuclei -u https://exemple.fr

# Scan ciblé sur les CVE critiques et élevées
nuclei -u https://exemple.fr -severity critical,high

# Sur une liste d'URL
nuclei -l urls.txt -o rapport-nuclei.txt

nuclei remonte typiquement : WordPress XML-RPC exposé, panel Adminer public, clé API dans un .js, version de jQuery vulnérable, bucket S3 public. Rapide (quelques minutes sur un site moyen), peu verbeux, exploitable directement.

4. Trivy — conteneurs et filesystem

Si vos clients ont une stack Docker (n8n, Nextcloud custom, API Node), Trivy scanne les images et le système de fichiers à la recherche de dépendances vulnérables. Indispensable en CI.

# Installation
sudo apt-get install -y wget apt-transport-https gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo "deb https://aquasecurity.github.io/trivy-repo/deb bookworm main" | \
  sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt update && sudo apt install -y trivy

# Scanner une image Docker
trivy image n8nio/n8n:latest

# Scanner le filesystem d'un projet (package.json, composer.lock, Gemfile.lock)
cd /var/www/vhosts/exemple.fr/httpdocs
trivy fs .

# Ne remonter que les CVE élevées
trivy image --severity HIGH,CRITICAL n8nio/n8n:latest

# Mode CI (exit code ≠ 0 si vuln trouvée)
trivy image --exit-code 1 --severity CRITICAL monimage:latest

Sortie typique : chaque dépendance listée avec la CVE, la version actuelle, la version corrigée. Le passage à la version corrigée règle presque toujours l'alerte.

5. Lynis — audit du serveur Debian

Quand vous reprenez un serveur hérité ou juste après une install, Lynis produit un audit complet de l'OS : config SSH, permissions de fichiers sensibles, firewall, règles PAM, kernel hardening. Le rapport est une checklist prête à dérouler.

# Installation
sudo apt install -y lynis

# Audit complet (à lancer en root)
sudo lynis audit system

# Rapport détaillé dans /var/log/lynis.log
sudo cat /var/log/lynis-report.dat | grep warning
sudo cat /var/log/lynis-report.dat | grep suggestion

Le « hardening index » en fin de rapport (note sur 100) donne une mesure synthétique. Un serveur Debian standard sort autour de 60, un serveur durci passe 85. Chaque suggestion est documentée avec un lien vers l'explication.

6. testssl.sh — audit TLS

Le couteau suisse pour tout ce qui touche HTTPS : protocoles activés (SSLv3 encore actif ?), ciphers faibles, certificats proches de l'expiration, HSTS, OCSP stapling, vulnérabilités historiques (Heartbleed, POODLE, ROBOT).

# Installation (script shell pur, pas de compil)
git clone --depth 1 https://github.com/drwetter/testssl.sh.git
cd testssl.sh

# Scan complet
./testssl.sh --full exemple.fr

# Rapport JSON pour parser en CI
./testssl.sh --jsonfile rapport-tls.json exemple.fr

# Juste les vulnérabilités historiques
./testssl.sh -U exemple.fr

L'équivalent SSL Labs en ligne de commande, qui tourne sans envoyer vos hostnames à un tiers. Sur un vhost Apache ou Nginx bien réglé, vous devez avoir tout vert et une note A+.

7. gitleaks — secrets dans le repo

Un .env ou une clé API oubliée dans un commit peut rester exploitable des mois. gitleaks scanne tout l'historique Git pour détecter les patterns de secrets connus (AWS, GCP, Stripe, Slack, tokens JWT, mots de passe en clair).

# Installation
wget https://github.com/gitleaks/gitleaks/releases/latest/download/gitleaks_linux_x64.tar.gz
tar -xzf gitleaks_linux_x64.tar.gz
sudo mv gitleaks /usr/local/bin/

# Scanner le repo courant (historique complet)
gitleaks detect --source . -v

# Scanner juste les changements non committés (pre-commit hook)
gitleaks protect --staged -v

Voir la doc dédiée Secrets et .env : ne pas les committer pour la mise en place du hook pre-commit et la rotation des secrets déjà fuités.

8. Mozilla Observatory — grade des headers

Test en ligne gratuit qui note de A+ à F les headers de sécurité : CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy. Donne aussi l'équivalent en ligne de commande via API.

# Via curl (API publique)
curl -X POST "https://http-observatory.security.mozilla.org/api/v1/analyze?host=exemple.fr"

# Puis récupérer le détail
curl "https://http-observatory.security.mozilla.org/api/v1/analyze?host=exemple.fr"

Objectif réaliste pour un site vitrine : note B minimum. A+ demande une CSP stricte qui casse souvent WordPress, à réserver aux sites buildés sans JS inline.

9. OWASP ZAP — le scanner complet

Proxy interceptor et scanner actif, développé par l'OWASP. Plus lourd à prendre en main que nuclei (GUI Java ou mode daemon), mais remonte des vulnérabilités applicatives que les autres manquent : XSS reflétées, injections SQL, CSRF, path traversal.

# Via Docker (le plus simple)
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t https://exemple.fr -r rapport-zap.html

# Scan actif (agressif, seulement sur vos sites)
docker run -t owasp/zap2docker-stable zap-full-scan.py \
  -t https://exemple.fr -r rapport-zap-full.html

Le baseline scan est passif (pas de requêtes offensives), utilisable en CI. Le full scan est actif et peut casser des formulaires ou déclencher des milliers d'entrées en base. À réserver à la recette.

Le combo « 10 minutes » pour un WordPress

Sur un site WordPress de client, ces trois commandes enchaînées couvrent l'essentiel :

# 1. Vulnérabilités WordPress
wpscan --url https://client.fr --enumerate vp,vt,u --api-token VOTRE_TOKEN

# 2. Templates CVE génériques
nuclei -u https://client.fr -severity critical,high

# 3. Grade des headers
curl -s -X POST "https://http-observatory.security.mozilla.org/api/v1/analyze?host=client.fr" \
  | jq '.grade, .score'

Total : 5 à 10 minutes d'horloge, un rapport exploitable, et les 3/4 des sites ont au moins une chose à corriger à l'arrivée.

Automatiser dans GitLab CI

Exemple minimal de .gitlab-ci.yml qui lance Trivy et nuclei à chaque push, sans bloquer le merge si des vulnérabilités basses sont trouvées :

security-scan:
  stage: test
  image: aquasec/trivy:latest
  script:
    - trivy fs --severity HIGH,CRITICAL --exit-code 1 .
  allow_failure: false

nuclei-scan:
  stage: test
  image: projectdiscovery/nuclei:latest
  script:
    - nuclei -u $STAGING_URL -severity critical,high -silent
  allow_failure: true
  only:
    - main

Le scan Trivy bloque le pipeline si une CVE critique est trouvée dans les dépendances (package.json, composer.lock). Le scan nuclei tourne sur l'URL de staging après déploiement, en mode informatif.

Ce que les scans ne couvrent pas

Un scan régulier et un pentest annuel sont complémentaires, pas substituables. Les scans chassent les oublis courants. Le pentest chasse ce qui est spécifique à votre application.

Récapitulatif

1. WPScan pour tout site WordPress. Avec token API pour les détails CVE.
2. Nikto pour les fichiers oubliés et les méthodes HTTP dangereuses.
3. nuclei pour un scan rapide et actuel des CVE connues.
4. Trivy dans la CI pour les images Docker et les dépendances.
5. Lynis après chaque install serveur, puis trimestriellement.
6. testssl.sh pour valider la config TLS après un renouvellement de cert.
7. gitleaks en hook pre-commit et en scan d'historique.
8. Mozilla Observatory pour la note headers, objectif B minimum.
9. OWASP ZAP en baseline pour la CI, en full scan pour la recette.
10. Scannez vos sites et ceux de vos clients mandatés, jamais au-delà.