Comment utiliser sqlmap : guide d'injection SQL (2026)

Qu'est-ce que sqlmap ?

sqlmap est un outil de test d'intrusion open source qui automatise la détection et l'exploitation des failles d'injection SQL. Vous lui donnez une requête contenant un paramètre que vous contrôlez, et il détermine si ce paramètre atteint une requête SQL, quelle technique permettra de récupérer des données, quel moteur de base de données se cache derrière l'application, puis il en extrait le contenu.

Il est écrit en Python, publié sous licence GPLv2, et préinstallé sur Kali Linux. La version 1.10.9 reconnaît 31 moteurs de bases de données, des évidents (MySQL, PostgreSQL, Oracle, Microsoft SQL Server, SQLite) à une longue liste que presque personne ne croise sur le terrain (Mckoi, FrontBase, Raima, eXtremeDB). Cette étendue compte moins qu'il n'y paraît. En pratique, vous verrez MySQL, PostgreSQL, MSSQL et SQLite encore et encore.

Ce qu'il faut comprendre avant votre première exécution, c'est ce que sqlmap n'est pas. Ce n'est pas un scanner de vulnérabilités web. Il ne va pas crawler une application et vous rendre une liste de bugs. Il teste les paramètres que vous lui désignez, et si vous n'avez pas fait la reconnaissance nécessaire pour savoir quels paramètres méritent d'être testés, vous ne faites que générer du trafic. La faiblesse sous-jacente qu'il traque, c'est CWE-89 : neutralisation incorrecte d'éléments spéciaux dans une commande SQL, classée troisième du CWE Top 25 des faiblesses logicielles les plus dangereuses publié par MITRE en 2024, avec un score de 35,88.

Si vous n'avez jamais vu la version manuelle de ce que fait cet outil, lisez d'abord le tutoriel sur l'injection SQL. sqlmap prendra beaucoup plus de sens une fois que vous aurez tapé vous-même ' OR 1=1 -- dans un formulaire de connexion et vu la requête s'effondrer.

Installer sqlmap en moins d'une minute

Sur Kali Linux, il est déjà là. Partout ailleurs, choisissez une méthode :

# Kali Linux (déjà installé)
sqlmap --version

# pip, sur tout OS disposant de Python 3
pip install sqlmap

# depuis les sources, pour suivre le développement
git clone --depth 1 https://github.com/sqlmapproject/sqlmap.git
cd sqlmap
python3 sqlmap.py --version

Le paquet pip et le clone git correspondent au même projet ; le clone vous donne simplement les commits les plus récents et vous permet de lire les scripts tamper. sqlmap fonctionne sous Python 2.7 et 3.x, même s'il n'y a plus aucune raison d'être en 2.7 en 2026. Si vous installez depuis les sources, notez que la commande devient python3 sqlmap.py et non sqlmap, ce qui bloque la moitié des gens qui suivent un tutoriel écrit pour l'autre méthode.

Une habitude à prendre tout de suite : lancez-le dans un environnement virtuel ou un conteneur plutôt qu'en root. sqlmap écrit des fichiers de session, des CSV extraits et des journaux dans votre répertoire personnel, et ces fichiers contiennent les données d'autres personnes.

Votre premier scan, ligne par ligne

La commande utile la plus simple, c'est une URL avec un paramètre et rien d'autre :

sqlmap -u "http://127.0.0.1:8099/product.php?id=1" --batch

--batch demande à sqlmap de répondre lui-même à ses questions avec l'option par défaut au lieu de s'arrêter pour vous en poser sept. Utilisez-le une fois que vous savez quelles sont ces questions. Les premières fois, laissez-le de côté et lisez-les.

Voici ce que sqlmap 1.10.9 a affiché quand j'ai lancé cette commande contre une page volontairement vulnérable sur ma propre machine, réduit aux lignes porteuses d'information :

[INFO] testing connection to the target URL
[INFO] checking if the target is protected by some kind of WAF/IPS
[INFO] testing if the target URL content is stable
[INFO] target URL content is stable
[INFO] testing if GET parameter 'id' is dynamic
[INFO] GET parameter 'id' appears to be dynamic
[INFO] heuristic (basic) test shows that GET parameter 'id' might be SQL injectable
[INFO] testing for SQL injection on GET parameter 'id'
[INFO] GET parameter 'id' appears to be 'AND boolean-based blind - WHERE or HAVING clause' injectable (with --string="Mug")
[INFO] heuristic (extended) test shows that the back-end DBMS could be 'SQLite'
[INFO] target URL appears to have 3 columns in query
[INFO] GET parameter 'id' is 'Generic UNION query (NULL) - 1 to 20 columns' injectable

Quatre de ces lignes méritent d'être mémorisées, parce que ce sont elles qui déterminent si la suite de l'exécution veut dire quelque chose.

• « target URL content is stable » signifie que la page renvoie le même contenu pour la même requête. Si sqlmap indique que le contenu n'est pas stable, il ne peut pas distinguer l'effet de votre payload du bruit normal de la page, et tous les résultats boolean-based qui suivent deviennent suspects. Corrigez avec --string ou --text-only.
• « parameter 'id' is dynamic » signifie que modifier la valeur a modifié la réponse. Un paramètre qui n'est pas dynamique n'atteint généralement aucune requête.
• « heuristic (basic) test shows ... might be SQL injectable », c'est sqlmap qui envoie un seul caractère cassant dans le paramètre et qui remarque une erreur de base de données. C'est le signal le plus rapide que vous obtiendrez, et c'est celui qui confirme le plus souvent ce que vous soupçonniez déjà à la main.
• « checking if the target is protected by some kind of WAF/IPS » mérite votre attention sur une mission réelle. Si un filtre est placé devant l'application, le silence ici ne veut pas dire qu'il n'y en a pas.

Ce scan complet a demandé 52 requêtes HTTP. Retenez ce chiffre : c'est la référence pour une décision que vous prendrez plus loin à propos de --level et --risk.

Comment lire le résumé des points d'injection

Quand sqlmap trouve quelque chose, il affiche un bloc que les débutants font défiler sans le lire. C'est la sortie la plus utile de toute l'exécution. Voici le bloc réel de ce scan :

sqlmap identified the following injection point(s) with a total of 52 HTTP(s) requests:
---
Parameter: id (GET)
    Type: boolean-based blind
    Title: AND boolean-based blind - WHERE or HAVING clause
    Payload: id=1 AND 6764=6764

    Type: error-based
    Title: SQLite >= 3.9 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (JSON path)
    Payload: id=1 AND 2526=JSON_EXTRACT(CHAR(123,125),...)

    Type: time-based blind
    Title: SQLite > 2.0 AND time-based blind (heavy query)
    Payload: id=1 AND 9391=LIKE(CHAR(65,66,67,68,69,70,71),UPPER(HEX(RANDOMBLOB(500000000/2))))

    Type: UNION query
    Title: Generic UNION query (NULL) - 3 columns
    Payload: id=1 UNION ALL SELECT CHAR(113,106,120,112,113)||...,NULL,NULL-- FBlf
---
back-end DBMS: SQLite

Chaque « Type » est une manière différente d'obtenir une réponse de la base de données, et elles ne se valent pas. Voici le classement qui compte quand vous attendez la fin d'une extraction lente :

1. UNION query. La base ajoute vos lignes au jeu de résultats réel et la page les affiche. Une seule requête peut renvoyer de nombreuses valeurs. Toujours la plus rapide, à privilégier dès que sqlmap la trouve.
2. Error-based. La base laisse fuiter la réponse à l'intérieur d'un message d'erreur. Presque aussi rapide que UNION, et efficace quand la page affiche les erreurs mais pas de lignes supplémentaires.
3. Boolean-based blind. La page a deux états visibles, vrai et faux, et sqlmap reconstruit les données bit par bit en posant des questions fermées. Lent mais fiable.
4. Time-based blind. Rien de visible ne change, alors sqlmap demande à la base de temporiser quand la réponse est oui, et chronomètre la réponse. Douloureusement lent et facilement perturbé par un réseau chargé. Si c'est votre seule option, comptez plusieurs heures pour une extraction.
5. Stacked queries. Le paramètre vous permet de terminer l'instruction et d'en exécuter une seconde. Ce n'est pas une méthode de récupération de données en soi, mais c'est la porte d'entrée vers l'écriture de fichiers et l'exécution de commandes.

La valeur par défaut --technique=BEUSTQ les essaie toutes, et sqlmap choisit la plus rapide disponible pour chaque tâche sans qu'on le lui dise. La raison de connaître ce classement malgré tout, c'est qu'il vous renseigne sur le comportement de l'application. Une cible où seule la technique time-based fonctionne est une cible qui ne vous montre jamais de sortie, et cela conditionne toute la suite. Si c'est votre situation, le guide sur l'injection SQL en aveugle couvre l'équivalent manuel, celui vers lequel vous vous rabattez quand l'outil n'avance plus.

Notez la dernière ligne : back-end DBMS: SQLite. Dès que sqlmap connaît le moteur, il cesse de tester les payloads des 30 autres et l'exécution raccourcit nettement. Si vous savez déjà ce que fait tourner la cible, passez --dbms=mysql et sautez complètement cette phase.

Du point d'injection aux données

Détection et extraction sont deux étapes distinctes. Une fois le point d'injection enregistré, vous ajoutez des options d'énumération et sqlmap réutilise ce qu'il sait déjà au lieu de tout retester :

# quelles bases existent
sqlmap -u "http://cible.example/product.php?id=1" --dbs

# les tables d'une base
sqlmap -u "http://cible.example/product.php?id=1" -D shopdb --tables

# les colonnes, pour savoir ce qui vaut la peine d'être extrait
sqlmap -u "http://cible.example/product.php?id=1" -D shopdb -T users --columns

# les données elles-mêmes, deux colonnes seulement
sqlmap -u "http://cible.example/product.php?id=1" -D shopdb -T users -C username,password --dump

Cet ordre de progression est délibéré. Les débutants dégainent --dump-all ou -a (tout récupérer) dès la première exécution, puis se demandent pourquoi le scan tourne depuis quarante minutes et pourquoi les journaux d'erreurs de la cible débordent. Descendez plutôt l'arbre : bases, tables, colonnes, puis les deux ou trois colonnes dont vous avez réellement besoin.

Voici le dump réel de ma cible de test :

Table: users
[2 entries]
+----+---------------------------------------------+----------+
| id | password                                    | username |
+----+---------------------------------------------+----------+
| 1  | 5f4dcc3b5aa765d61d8327deb882cf99 (password) | dana     |
| 2  | e10adc3949ba59abbe56e057f20f883e (123456)   | ravi     |
+----+---------------------------------------------+----------+

[INFO] table 'users' dumped to CSV file '/root/.local/share/sqlmap/output/127.0.0.1/dump/users.csv'

Regardez les parenthèses. sqlmap a reconnu ces valeurs comme des empreintes MD5, a proposé une attaque par dictionnaire et a cassé les deux avec sa liste de mots intégrée. C'est un vrai bon détail, et aussi un rappel de la vitesse à laquelle du MD5 non salé s'effondre. La dernière ligne compte également : tout ce que sqlmap récupère est écrit sur le disque, dans votre répertoire personnel. Sur une mission réelle, ce fichier devient une preuve dont vous êtes responsable.

Deux options méritent d'entrer dans vos réflexes ici. --count vous indique combien de lignes contient une table avant de vous engager dans son extraction, ce qui vous évite de lancer une extraction en aveugle de 400 000 enregistrements. Et --where="id<10" vous permet de prélever un échantillon représentatif au lieu de la table entière, ce qui suffit généralement à un rapport.

Les options qui changent vraiment vos résultats

sqlmap compte des centaines d'options. Six d'entre elles couvrent à peu près tout ce que vous ferez pendant votre première année.

-r : charger une requête depuis un fichier

C'est l'option la plus utile de l'outil et celle que les tutoriels mentionnent en dernier. Au lieu de reconstruire une requête complexe en ligne de commande avec --data, --cookie et quatre -H, capturez la requête dans Burp Suite, enregistrez-la dans un fichier et donnez le fichier à sqlmap :

sqlmap -r login-request.txt -p username --batch

Chaque en-tête, cookie et paramètre de corps est transmis exactement comme le navigateur l'a envoyé. Pour tout ce qui se trouve derrière une authentification, pour les API JSON ou les formulaires multipart, c'est la seule approche raisonnable. Ajoutez --force-ssl si la requête enregistrée ne conserve pas le schéma.

-p : nommer le paramètre

Sans -p, sqlmap teste tous les paramètres qu'il trouve, y compris les cookies et les en-têtes aux niveaux élevés. Si votre reconnaissance indique que le bug est dans search, dites-le. Un test ciblé se termine en une fraction du temps et génère une fraction du bruit.

--level et --risk : n'y touchez pas au début

Voici l'avis tranché : le réflexe d'ouvrir avec --level 5 --risk 3 est mauvais, et c'est l'erreur la plus courante des débutants avec cet outil. Ces options contrôlent le nombre de payloads que sqlmap essaie et le niveau de danger qu'ils sont autorisés à atteindre.

Je l'ai mesuré. Contre un paramètre non injectable, sqlmap 1.10.9 a exécuté 11 groupes de tests aux valeurs par défaut (--level 1 --risk 1) et 172 avec --level 5 --risk 3, tout le reste étant identique. Cela fait environ quinze fois plus de tests pour arriver à la même réponse, et sur une cible lente cela transforme une vérification de deux minutes en pause café. Pire, le niveau de risque 3 inclut des payloads à base de OR qui peuvent correspondre à toutes les lignes d'une table, ce qui, sur une instruction DELETE ou UPDATE, est la façon dont on efface accidentellement des données pendant un test autorisé.

Lancez les valeurs par défaut. Si le paramètre semble réellement injectable et revient propre, augmentez alors le niveau, un cran à la fois. Le niveau 2 ajoute le test des cookies, le niveau 3 ajoute User-Agent et Referer, et le niveau 5 teste des en-têtes que la plupart des applications ne placent jamais dans une requête.

--tamper : quand un filtre déforme votre payload

Si un filtre d'entrée supprime les espaces ou normalise les mots-clés, le payload qui fonctionne à la main peut n'arriver jamais intact. Les scripts tamper réécrivent les payloads sous des formes équivalentes, et la 1.10.9 en fournit 84 :

sqlmap -u "http://cible.example/p?id=1" --tamper=space2comment,randomcase --batch

space2comment remplace les espaces par /**/, randomcase fait varier la casse des mots-clés, between remplace les opérateurs de comparaison. Lancez --list-tampers pour tous les lire. N'en empilez pas six en espérant que ça passe : choisissez celui qui correspond au comportement de filtrage que vous avez observé, car les scripts tamper modifient le payload d'une manière qui peut casser une injection qui fonctionnait.

--batch et le fichier de session

La première fois que vous relancerez sqlmap contre la même cible, vous verrez ceci :

[INFO] resuming back-end DBMS 'sqlite'
sqlmap resumed the following injection point(s) from stored session:

sqlmap met en cache tout ce qu'il apprend dans un fichier de session SQLite propre à chaque cible. C'est pour cela que la deuxième exécution se termine instantanément, et aussi pour cela qu'un résultat périmé peut vous suivre après une modification de l'application. --flush-session le vide et repart de zéro. Si un scan se comporte d'une manière incompréhensible, vider la session est la première chose à essayer.

--threads : de la vitesse, avec prudence

L'extraction en aveugle, c'est une requête par caractère : --threads 5 peut réellement raccourcir une longue extraction. Au-delà de 10, vous martelez la cible, et sur une infrastructure de production c'est ainsi qu'un test devient une panne. Cinq est un plafond raisonnable pour un travail autorisé.

Quand sqlmap dit « non injectable » alors que vous savez qu'il l'est

C'est le moment qui envoie les gens sur les forums. Vous avez trouvé le bug manuellement, sqlmap n'est pas d'accord, et la tentation est de pousser toutes les options au maximum. Passez plutôt en revue cette liste, dans l'ordre.

• Vous n'avez pas envoyé de session valide. De loin la cause la plus fréquente. sqlmap a reçu une redirection vers la page de connexion à chaque requête et a consciencieusement conclu que rien n'était injectable. Utilisez -r avec une requête authentifiée capturée.
• Le paramètre n'est pas celui que vous croyez. Ajoutez -p et nommez-le explicitement. S'il vit dans du JSON ou dans un cookie, -r gère correctement son emplacement.
• La réponse est instable. Horodatages, jetons CSRF ou publicités tournantes modifient la page à chaque requête, et sqlmap ne peut plus comparer les réponses. Donnez-lui un repère : --string="Bienvenue" pour un texte qui n'apparaît que sur les réponses vraies, ou --text-only pour ignorer le balisage.
• Un jeton anti-CSRF rejette chaque requête. Indiquez-le à sqlmap avec --csrf-token=nom_du_jeton et il en récupérera un nouveau avant chaque requête.
• Un filtre réécrit le payload. C'est maintenant le moment d'utiliser --tamper, et c'est aussi maintenant le moment d'augmenter --level. Pas avant.
• L'injection est de second ordre. Le payload est stocké sur une page et exécuté quand une autre page l'affiche. sqlmap gère ce cas avec --second-url, mais encore faut-il savoir que la seconde page existe, et aucun scanner ne vous le dira.

Il y a aussi l'honnête possibilité que le paramètre soit correctement paramétré et que vous vous soyez trompé. Cela arrive plus souvent que les fils de forum ne le laissent penser, et cela vaut la peine de le vérifier plutôt que d'escalader pendant une heure de plus. Une requête préparée ne laisse aucune prise à sqlmap, et aucune combinaison d'options n'y changera rien.

Faut-il utiliser sqlmap en CTF ?

Les débutants devraient-ils utiliser sqlmap en CTF ? Pas pour les dix premiers défis. Automatiser une compétence que vous n'avez jamais exercée à la main vous laisse incapable de distinguer une vraie trouvaille d'un faux positif, et incapable d'avancer quand l'outil se bloque. Résolvez les défis web à la main jusqu'à savoir construire un payload UNION vous-même, puis laissez sqlmap prendre le relais sur l'extraction répétitive.

Il y a une raison pratique autant que pédagogique. sqlmap figure sur la liste des outils restreints de l'examen OSCP, aux côtés d'autres outils d'exploitation automatisée ; l'objectif affiché par OffSec est d'évaluer votre capacité à identifier et exploiter des vulnérabilités, pas à automatiser le processus. Si votre plan inclut cette certification, chaque heure passée à lancer sqlmap au lieu d'écrire des payloads est une heure de préparation en moins. Les règles actuelles figurent dans le guide de l'examen OSCP, et elles changent de temps en temps : vérifiez avant de le passer.

Là où sqlmap justifie sa place en CTF, c'est juste après la découverte. Vous avez prouvé qu'une injection boolean-based blind existe, et il vous faut maintenant sortir 400 caractères d'une table, bit par bit. Le faire à la main, ce n'est pas apprendre, c'est taper au clavier. C'est exactement le travail pour lequel l'outil a été construit.

Une dernière habitude sépare ceux qui progressent de ceux qui stagnent : après que sqlmap a trouvé quelque chose, lisez le payload qu'il a utilisé. Il est affiché dans le résumé des points d'injection. Cherchez pourquoi AND 6764=6764 prouve quoi que ce soit, et pourquoi le payload UNION contient trois NULL. C'est toute la leçon, et elle se trouve dans la sortie de chaque exécution réussie.

Considérations légales et éthiques

• Confirmez le périmètre par écrit avant la première requête : quels hôtes, quels paramètres, à quelles heures.
• Gardez --risk à 1 tant que le client n'a pas explicitement accepté l'éventualité d'une modification des données.
• Extrayez le minimum nécessaire pour prouver l'impact. Une ligne d'une table sensible démontre la faille ; la table entière est une fuite dont vous êtes l'auteur.
• Les données extraites atterrissent sur votre disque en CSV en clair. Chiffrez-les, signalez-les, puis supprimez-les.
• Sur les programmes de bug bounty, lisez d'abord les règles sur l'outillage automatisé. Plusieurs programmes majeurs interdisent purement et simplement les scanners automatiques, et sqlmap en fait partie.

Pour la face défensive de la même pièce, la référence OWASP sur l'injection SQL et son aide-mémoire sur le paramétrage des requêtes sont les documents à transmettre à votre équipe de développement.