Comment utiliser Nikto : tutoriel du scanner web (2026)

Qu'est-ce que Nikto ?

Nikto est un scanner open source qui teste un serveur web contre une base de fichiers dangereux connus, de versions logicielles obsolètes et de mauvaises configurations courantes. Il demande chaque chemin de sa base, compare la réponse à un jeu de règles de correspondance, et affiche les chemins qui ressemblent à un résultat.

Chris Sullo le maintient depuis 2001. Il est écrit en Perl, s'appuie sur la bibliothèque HTTP LibWhisker, et est publié sous GPLv3, même si les bases de vérifications ont leur propre licence et ne peuvent pas être réutilisées dans d'autres outils. La page officielle du projet sur cirt.net annonce une couverture de « plus de 8 000 fichiers et programmes potentiellement dangereux ou intéressants », plus les versions obsolètes de milliers de serveurs et de composants. Si vous clonez le dépôt et comptez, le fichier principal db_tests de la 2.6.1 contient 7 288 lignes, le reste de la couverture étant réparti sur une douzaine d'autres fichiers de base.

Voici ce que personne ne vous dit le premier jour, et cela explique l'essentiel de la déception que certains ont avec cet outil.

Nikto ne crawle pas. Il ne lit jamais un lien sur votre cible pour le suivre. Il possède une liste de chemins qu'il connaît déjà, et il les demande tous. C'est un travail radicalement différent de celui d'un scanner d'application web, qui cartographie l'application d'abord et attaque ensuite ce qu'il a trouvé.

Nikto est donc excellent pour trouver ce que tout le monde laisse traîner : /.env, /phpinfo.php, /backup/, une console d'administration sur un chemin par défaut, une bannière serveur qui trahit la stack. Il est inutile pour trouver le contrôle d'autorisation cassé dans /api/v2/orders/1041, parce que rien dans sa base n'a jamais entendu parler de cette URL.

Installer Nikto et vérifier sa version

Sur Kali il est déjà installé, et le paquet Kali actuel est en 2.6.1. Sur Debian ou Ubuntu, c'est une seule commande :

sudo apt update
sudo apt install nikto

Vérifiez ce que vous avez réellement obtenu avant toute chose :

nikto -Version

Nikto 2.6.1 (LW 2.5)

Ce « LW 2.5 » correspond à la version de LibWhisker en dessous. La version 2.6.1 est sortie le 31 juillet 2024 et vaut la peine d'être installée : elle a ajouté les connexions TLS keep-alive pour des scans environ 18 % plus rapides, est passée à un user agent Chrome statique par défaut au lieu d'en changer à chaque requête, et a ajouté le format de sortie sqld qui écrit les résultats directement dans une base MySQL ou PostgreSQL.

Si votre distribution fournit une version plus ancienne, lancez-le depuis l'arbre des sources à la place :

git clone https://github.com/sullo/nikto
cd nikto/program
perl nikto.pl -Version

En pratique, ce clone échoue sur une machine vierge avec ERROR: Required module not found: XML::Writer et rien d'autre. Nikto vérifie ses dépendances Perl avant d'afficher quoi que ce soit, donc un module manquant ressemble à un outil cassé. Installez-le et la même commande fonctionne :

sudo apt install libxml-writer-perl

Il existe aussi un conteneur officiel si vous préférez ne pas toucher à Perl du tout :

docker pull ghcr.io/sullo/nikto:latest

Votre premier scan Nikto

Un seul flag fait le travail. -h accepte un nom d'hôte, une IP ou une URL complète :

nikto -h http://127.0.0.1:8000/

Voici un vrai scan contre un serveur web Python volontairement négligé, tronqué uniquement là où le même résultat se répète :

- Nikto v2.6.1
---------------------------------------------------------------------------
+ Target IP:          127.0.0.1
+ Target Hostname:    127.0.0.1
+ Target Port:        8000
+ Start Time:         2026-09-08 07:20:21 (GMT0)
---------------------------------------------------------------------------
+ Server: SimpleHTTP/0.6 Python/3.11.15
+ No CGI Directories found (use '-C all' to force check all possible dirs).
+ [013587] /: Suggested security header missing: content-security-policy.
+ [013587] /: Suggested security header missing: strict-transport-security.
+ [013587] /: Suggested security header missing: x-content-type-options.
+ [600720] SimpleHTTP/0.6 appears to be outdated (current is at least 1.2).
+ [600652] Python/3.11.15 appears to be outdated (current is at least 3.14.6).
+ [001578] /backup/: This might be interesting.
+ [007226] /.env: .env file found. The .env file may contain credentials.
+ 8143 requests: 4 errors and 11 items reported on the remote host
+ End Time:           2026-09-08 07:20:50 (GMT0) (11 seconds)

Huit mille requêtes en onze secondes, parce que la cible est sur localhost. Contre un vrai hôte sur internet, le même scan prend plusieurs minutes.

Les nombres entre crochets sont les identifiants de test de Nikto, un par ligne dans la base de vérifications. Ils ont remplacé les références OSVDB que beaucoup de tutoriels affichent encore, parce qu'OSVDB a fermé en 2016. Ils servent à une chose : chercher dans la base ce qu'une vérification a exactement testé.

Deux lignes de cette sortie sont des résultats. Le reste est du contexte.

Lire la sortie de Nikto sans se tromper soi-même

Nikto rapporte tout ce qui a déclenché une correspondance et vous laisse le jugement. C'est le bon choix de conception, et cela signifie que la sortie ci-dessus contient un résultat réel, une piste et un tas de bruit.

Le vrai résultat, c'est /.env. Un fichier d'environnement lisible publiquement contient en général des identifiants de base de données, des clés d'API et un secret de framework. Cette seule ligne vaut plus que tout le reste du scan réuni, et c'est la première chose à ouvrir.

La piste, c'est /backup/. « This might be interesting » est la façon dont Nikto vous dit qu'un répertoire existe et que les gens le laissent souvent ouvert. Ce n'est pas une vulnérabilité. C'est un endroit où pointer votre outil suivant.

Le bruit, c'est le bloc des en-têtes de sécurité. Cinq lignes pour vous dire qu'un serveur de test Python n'a pas de Content-Security-Policy. Dans un rapport client, elles vont dans la section de sévérité faible. Dans un capture the flag, elles vont à la poubelle.

Restent les vérifications de version, et c'est là que les débutants se font avoir :

+ [600720] SimpleHTTP/0.6 appears to be outdated (current is at least 1.2).

C'est faux. SimpleHTTP est le serveur de la bibliothèque standard de Python et il n'existe aucune version 1.2. Nikto a fait correspondre la bannière à une entrée de db_outdated concernant un produit sans rapport au nom similaire, et l'a rapporté avec une confiance totale. La ligne Python 3.11 au-dessus est techniquement vraie et ne vous dit toujours rien sur le fait que la machine soit exploitable.

Chaque résultat de version que Nikto rapporte est une comparaison de chaîne avec une bannière que le serveur a choisi d'envoyer. Les serveurs mentent sur leurs bannières. Les reverse proxies les réécrivent. Les correctifs de sécurité rétroportés laissent volontairement le numéro de version inchangé, ce qui explique qu'un Apache Debian entièrement à jour annonce une version qui semble vieille de plusieurs années. Confirmez vous-même le logiciel et sa version avant de l'écrire, et n'enchaînez jamais directement sur un exploit sur la foi d'une correspondance de bannière Nikto.

Un ordre de tri qui fonctionne : d'abord les identifiants et fichiers de configuration, puis les répertoires à énumérer, puis l'identification logicielle, puis les en-têtes.

Les flags qui changent le scan

Nikto a une cinquantaine d'options. Voici celles qui changent ce qui se passe, plutôt que l'apparence du résultat.

Réduire le scan avec -Tuning

-Tuning sélectionne les catégories de vérifications à lancer. Les codes tiennent en un caractère et vous les concaténez :

• 1 fichiers intéressants, 2 mauvaise configuration et fichiers par défaut, 3 divulgation d'information
• 4 injection (XSS, script, HTML), 9 injection SQL, 0 upload de fichiers
• 5 et 7 récupération de fichiers distants, dans la racine web et sur tout le serveur
• 6 déni de service, 8 exécution de commandes, a contournement d'authentification
• b identification logicielle, c inclusion de source distante, d services web, e consoles d'administration
• x inverse la sélection, donc -Tuning x6 lance tout sauf les vérifications de déni de service

La combinaison purement reconnaissance est celle à mémoriser :

nikto -h http://cible -Tuning 123b

Fichiers, mauvaises configurations, divulgation d'information et identification logicielle. Sur la même cible que plus haut, cela a fait passer le scan de 8 143 à 4 297 requêtes tout en retrouvant les onze mêmes éléments. Moitié moins de trafic, aucune perte, parce que les catégories injection et déni de service n'allaient jamais se déclencher sur un serveur de fichiers statiques.

Coupez toujours la catégorie 6 sur tout ce que vous n'avez pas construit vous-même. Ces vérifications cherchent des conditions de déni de service en les déclenchant.

Le pointer sur la bonne chose

• -p 80,443,8080,8443 scanne plusieurs ports en une seule exécution. Nikto gère seul le passage entre HTTP et HTTPS.
• -root /app/ préfixe un chemin à toutes les requêtes. Indispensable quand l'application vit dans un sous-répertoire et qu'un scan de / ne renvoie rien.
• -vhost dev.acme.example définit l'en-tête Host tout en se connectant à l'IP que vous avez donnée. L'hébergement mutualisé et les ingress Kubernetes servent des sites différents selon le nom d'hôte, donc scanner l'IP sans cette option teste souvent le mauvais site.
• -C all force les vérifications de répertoires CGI que le scan par défaut ignore. Une exécution vaut le coup sur tout ce qui est ancien.
• -maxtime 5m plafonne la durée. Utile quand une cible lente laisserait sinon le scan tourner tout l'après-midi.
• -useproxy http://127.0.0.1:8080 fait passer le tout par un proxy, ce qui place l'ensemble du scan dans l'historique de Burp Suite où vous pouvez rejouer chaque requête.

Sauvegarder les résultats

nikto -h http://cible -o scan.json -Format json
nikto -h http://cible -o rapport.html -Format htm

Le JSON vous donne un tableau vulnerabilities avec id, url, method, msg et references par résultat, ce qu'il vous faut si quelque chose en aval doit l'analyser. Le rapport HTML est celui à joindre à un ticket. Les formats se combinent avec des virgules, et si vous omettez -Format, Nikto le devine depuis l'extension du fichier.

Quand tous les chemins remontent comme des résultats

Certains serveurs répondent 200 OK pour des URL qui n'existent pas, ce qui fait ressembler chaque vérification de la base à un résultat. Nikto essaie de détecter ce comportement en demandant des chemins aléatoires au démarrage, et quand cela échoue, vous lui indiquez à quoi ressemble un échec :

nikto -h http://cible -404string "Page not found"
nikto -h http://cible -404code 302

Si un scan renvoie des centaines de résultats sur une application monopage moderne, c'est presque toujours la raison.

Où Nikto s'insère dans une vraie reconnaissance

Nikto est une étape, pas une méthodologie. L'ordre qui fonctionne sur une machine de CTF et sur une mission client est le même :

1. Scan de ports d'abord. Vous ne pouvez pas scanner un serveur web que vous n'avez pas trouvé. Un scan de services Nmap vous dit quels ports parlent HTTP. Nikto analyse la sortie greppable de Nmap, donc un scan sauvegardé avec -oG ports.gnmap peut être passé directement à -h et chaque port web ouvert est mis en file : + Nmap Input Queued: 127.0.0.1:8000. La sortie XML ne fonctionne pas, uniquement la greppable.
2. Regardez le site vous-même. Trente secondes dans le navigateur et dans le code source battent n'importe quel scanner. Les frameworks se trahissent dans les commentaires, les chemins de scripts et les noms de cookies.
3. Lancez Nikto en arrière-plan. Démarrez nikto -h http://cible -Tuning 123b -o nikto.txt dans un panneau et continuez à lire dans un autre. Le laisser tourner ne vous coûte rien.
4. Forcez ce que Nikto ne peut pas connaître. Nikto ne demande que les chemins de sa base. Les répertoires personnalisés exigent une wordlist, et c'est à cela que servent Gobuster et ffuf. Les deux outils se recouvrent bien moins qu'on ne le croit : l'un demande des fichiers connus comme risqués, l'autre devine des noms.
5. Emmenez les pistes dans un proxy. Chaque résultat qui mérite d'être creusé s'ouvre dans Burp et se teste à la main.

L'erreur à éviter, c'est de prendre un scan Nikto vide pour une cible saine. Sur une application moderne, un scan sans aucun résultat est le résultat normal. Cela signifie que personne n'a laissé traîner un vieux panneau d'administration, pas que l'application est sécurisée.

Quand Nikto est le mauvais outil

Les limites honnêtes, pour que vous arrêtiez d'y recourir dans des situations où il ne peut pas aider :

• Les applications web modernes. Pas de crawl, pas de gestion de session, pas de JavaScript. Une application monopage pilotée par API lui est quasiment invisible. Utilisez un proxy et votre propre lecture du trafic.
• Tout ce qui est derrière un WAF ou un CDN. Des milliers de requêtes pour /phpinfo.php et consorts, c'est le comportement type d'un scanner. Cloudflare et ses concurrents bloquent ou défient le scan, et chaque résultat après ce point n'a plus de sens.
• Les zones authentifiées. -id user:pass gère l'authentification HTTP Basic et NTLM, et rien d'autre. Il n'y a aucun support pour se connecter via un formulaire, donc tout ce qui se trouve après la page de connexion est hors de portée.
• La logique métier et le contrôle d'accès. Le contrôle d'autorisation cassé est le premier point du Top 10 OWASP, et aucun scanner basé sur des chemins ne le trouvera jamais. C'est du travail manuel.
• Confirmer une vulnérabilité. Nikto vous dit que quelque chose semble anormal. Le prouver, et prouver l'impact, c'est votre travail.

Un flag mérite une note parce que les tutoriels le présentent mal. -evasion applique des astuces d'encodage de requêtes comme les auto-références de répertoires et les changements de casse d'URL. Son usage honnête est du côté défensif : lancez le même scan avec et sans, et voyez si votre propre supervision le détecte toujours. Comme moyen de faire passer un scan à travers les contrôles de quelqu'un d'autre, c'est une technologie vieille de vingt ans, et les défenses actuelles la gèrent sans difficulté.

Là où Nikto garde toute sa place, c'est sur l'infrastructure ancienne et interne, et sur les machines de CTF conçues pour être énumérées. L'application intranet que personne n'a redéployée depuis 2018, l'interface web de l'imprimante, le serveur de préproduction avec le listing de répertoires activé : c'est là que quelques milliers de requêtes automatisées trouvent quelque chose dans la première minute et vous font gagner une heure.

Considérations légales et éthiques

• Ne scannez que les hôtes nommés dans un document de périmètre signé, ou les environnements de lab que vous avez construits vous-même
• Excluez la catégorie de tuning 6 sauf si les tests de déni de service sont explicitement dans le périmètre et par écrit
• L'hébergement mutualisé signifie qu'une IP peut servir des centaines de sites. Confirmez la cible avec -vhost plutôt que de scanner une adresse en espérant
• Les identifiants trouvés dans un fichier de configuration exposé vont dans le rapport, pas dans un formulaire de connexion, sauf si le périmètre l'autorise
• Prévenez le client avant de commencer. Un scanner dans les journaux ressemble exactement à une attaque, et des équipes bleues ont ouvert des incidents pour moins que ça

Les plateformes de CTF et les cibles volontairement vulnérables existent pour que vous puissiez lancer tout cela sans avoir tout ce qui précède au-dessus de la tête. Servez-vous-en.

Questions fréquentes