Sécurité des API REST — Rapport de Recherche

SÉCURITÉ DES API REST

Rapport de Recherche

Module : Audit de Sécurité Informatique

2025 — 2026

Module : Audit de Sécurité Informatique | Page 1

Sécurité des API REST — Rapport de Recherche

1. Introduction aux API REST

1.1 Définition
Une API (Application Programming Interface) est une interface qui permet à deux
applications de communiquer entre elles. Elle joue le rôle d'un intermédiaire entre un client
(navigateur, application mobile...) et un serveur.

REST (Representational State Transfer) est un style d'architecture qui définit un ensemble
de règles pour concevoir des API. Une API qui respecte ces règles est appelée API REST
ou API RESTful.

1.2 Comment ça fonctionne ?

Le principe est simple : le client envoie une requête HTTP au serveur, et le serveur répond
avec des données (généralement en format JSON ou XML).

Exemple concret :
GET /users/123 → { "id": 123, "nom": "Yacine", "email": "yacine@[Link]"
}

1.3 Les méthodes HTTP principales

Méthode Action Exemple

GET Récupérer des données GET /users/123
POST Créer une ressource POST /users
PUT Modifier une ressource PUT /users/123
DELETE Supprimer une ressource DELETE /users/123

1.4 Les principes clés de REST

• Chaque ressource est identifiée par une URL unique
• La communication est sans état (le serveur ne garde pas en mémoire les requêtes
précédentes)
• Les échanges se font via le protocole HTTP/HTTPS
• Les réponses sont généralement au format JSON ou XML

Module : Audit de Sécurité Informatique | Page 2

Sécurité des API REST — Rapport de Recherche

2. Les vulnérabilités les plus courantes — OWASP

API Security Top 10

L'OWASP (Open Web Application Security Project) est une organisation mondiale qui
référence les risques de sécurité les plus critiques. Ils ont publié un Top 10 spécifique aux
API qui est une référence incontournable dans le domaine.

API1 — Broken Object Level Authorization (BOLA)

La vulnérabilité la plus fréquente. Un utilisateur peut accéder aux données d'un autre en
modifiant simplement un identifiant dans l'URL.

Exemple :
GET /api/accounts/1001/solde → Normal
GET /api/accounts/1002/solde → Accès aux données d'une autre personne !

Cas réel : Venmo en 2019 — les transactions de n'importe quel utilisateur étaient
accessibles publiquement via leur API.

API2 — Broken Authentication

Les mécanismes d'authentification mal implémentés permettent aux attaquants de se faire
passer pour d'autres utilisateurs.

Exemple : Un attaquant modifie un token JWT pour changer son rôle de 'user' à 'admin'. Si
le serveur ne vérifie pas la signature, il obtient des privilèges administrateur.

API3 — Broken Object Property Level Authorization

L'API expose des propriétés sensibles qu'un utilisateur ne devrait pas voir ou modifier (Mass
Assignment).

PUT /api/users/123 { "nom": "Yacine", "role": "admin", "solde": 99999 }

API4 — Unrestricted Resource Consumption

L'API ne limite pas les requêtes, permettant à un attaquant de surcharger le serveur avec
des milliers de requêtes par seconde (attaque DoS).

API5 — Broken Function Level Authorization

Un utilisateur normal peut accéder à des fonctions réservées aux administrateurs.

DELETE /api/admin/users/456 → Accessible à un simple utilisateur !

API6 — Unrestricted Access to Sensitive Business Flows

Module : Audit de Sécurité Informatique | Page 3

Sécurité des API REST — Rapport de Recherche

Des processus métier sensibles sont exposés sans protection. Exemple : des bots qui
achètent tout le stock de sneakers en édition limitée avant les vrais clients (Nike, Adidas).

API7 — Server Side Request Forgery (SSRF)

L'attaquant manipule l'API pour qu'elle envoie des requêtes vers des ressources internes du
serveur.

POST /api/fetch-image { "url": "[Link] }

Cas réel : Vol de données de Capital One en 2019 — 100 millions de clients affectés.

API8 — Security Misconfiguration

Des mauvaises configurations exposent des informations sensibles, comme laisser des
messages d'erreur trop détaillés contenant des identifiants de base de données.

API9 — Improper Inventory Management

Des anciennes versions vulnérables de l'API restent accessibles et non maintenues,
constituant une porte d'entrée pour les attaquants.

API10 — Unsafe Consumption of APIs

L'application fait confiance sans vérification aux données reçues d'APIs tierces, pouvant
introduire des attaques XSS si ces APIs sont compromises.

Module : Audit de Sécurité Informatique | Page 4

Sécurité des API REST — Rapport de Recherche

3. Les mécanismes d'authentification et

d'autorisation

Il est essentiel de distinguer ces deux concepts fondamentaux :

• Authentification → Qui es-tu ? (vérifier l'identité)
• Autorisation → Qu'as-tu le droit de faire ? (vérifier les permissions)

3.1 Les API Keys

Le mécanisme le plus simple. Le serveur génère une clé unique pour chaque client, qui doit
l'envoyer dans chaque requête.

GET /api/data | Headers: X-API-Key: abc123xyz456

Inconvénients : Si la clé est volée, n'importe qui peut l'utiliser. Beaucoup de développeurs
publient accidentellement leurs API Keys sur GitHub.

3.2 JWT (JSON Web Token)

C'est le mécanisme le plus utilisé aujourd'hui. Un JWT est un token composé de 3 parties
séparées par un point :

[Link]
| | |
Header Payload Signature

Fonctionnement :
1. L'utilisateur se connecte avec son login/mot de passe
2. Le serveur génère un JWT et le renvoie au client
3. Le client stocke ce token et l'envoie dans chaque requête
4. Le serveur vérifie la signature du token pour valider l'identité

Failles courantes des JWT :

• Algorithme 'none' : le serveur accepte des tokens non signés
• Clé secrète faible : trouvable par force brute si trop simple
• Pas de vérification de l'expiration : tokens expirés acceptés

3.3 OAuth 2.0

Protocole d'autorisation avancé utilisé quand une application veut accéder aux ressources
d'un utilisateur sur un autre service. Exemple typique : 'Se connecter avec Google'.

Acteur Rôle Exemple

Resource Owner L'utilisateur Toi
Client L'application Un site web
Authorization Server Délivre le token Google
Resource Server Possède les données Gmail API

Module : Audit de Sécurité Informatique | Page 5

Sécurité des API REST — Rapport de Recherche

3.4 Comparaison des mécanismes

Critère API Key JWT OAuth 2.0

Complexité Simple Moyenne Complexe
Sécurité Faible Bonne Très bonne
Expiration Non Oui Oui
Cas d'usage APIs simples APIs modernes Connexion via tiers

Module : Audit de Sécurité Informatique | Page 6

Sécurité des API REST — Rapport de Recherche

4. Les techniques d'attaque sur les API REST

4.1 Injection SQL

L'attaquant insère du code SQL malveillant dans une requête API pour manipuler la base de
données.

GET /api/users?id=1 OR 1=1-- → Retourne TOUS les utilisateurs

GET /api/users?id=1; DROP TABLE users-- → Supprime la base !

4.2 Injection NoSQL

Similaire à l'injection SQL mais pour les bases de données NoSQL comme MongoDB.
L'opérateur $gt (greater than) fait que la condition est toujours vraie.

POST /api/login { "email": { "$gt": "" }, "password": { "$gt": "" } }

4.3 IDOR (Insecure Direct Object Reference)

L'attaquant accède directement à des ressources qui ne lui appartiennent pas en modifiant
un identifiant.

GET /api/factures/1001 → Ta facture

GET /api/factures/1002 → Facture d'un autre utilisateur !

Cas réel : En 2021, une faille IDOR sur l'API de Parler a permis de télécharger des millions
de posts supprimés.

4.4 Attaque par Force Brute

L'attaquant essaie des milliers de combinaisons de mots de passe automatiquement jusqu'à
trouver le bon, avec des outils comme Hydra ou Burp Suite.

4.5 Man-in-the-Middle (MitM)

L'attaquant se place entre le client et le serveur pour intercepter et lire les communications.
Si une API utilise HTTP au lieu de HTTPS, toutes les données circulent en texte clair et
peuvent être interceptées sur un réseau WiFi public avec Wireshark.

4.6 Attaque DDoS

Des milliers de machines envoient simultanément des requêtes massives pour saturer et
faire tomber le serveur.

Cas réel : En 2016, l'attaque DDoS contre Dyn a mis hors ligne Twitter, Netflix et Amazon
pendant plusieurs heures.

Module : Audit de Sécurité Informatique | Page 7

Sécurité des API REST — Rapport de Recherche

4.7 XXE (XML External Entity)

L'attaquant injecte du code XML malveillant pour accéder aux fichiers internes du serveur.

<!DOCTYPE user [<!ENTITY secret SYSTEM "[Link]

4.8 Attaque par Replay

L'attaquant capture une requête valide (par exemple un virement bancaire) et la rejoue
plusieurs fois pour répéter la même transaction.

Résumé des attaques

Attaque Cible Impact

Injection SQL Base de données Vol/suppression de données
IDOR Ressources Accès non autorisé
Force Brute Authentification Prise de compte
MitM Communication Vol de données
DDoS Disponibilité Mise hors ligne
XXE Serveur Accès fichiers internes
Replay Transactions Fraude financière

Module : Audit de Sécurité Informatique | Page 8

Sécurité des API REST — Rapport de Recherche

5. Les bonnes pratiques de sécurisation

5.1 Utiliser HTTPS obligatoirement

HTTPS chiffre toutes les communications entre le client et le serveur, empêchant les
attaques Man-in-the-Middle.

❌ [Link]
✅ [Link]

5.2 Authentification et autorisation solides

• Utiliser JWT ou OAuth 2.0 plutôt que des sessions simples
• Définir une durée d'expiration courte pour les tokens (ex: 15 minutes)
• Appliquer le principe du moindre privilège
• Toujours vérifier côté serveur les droits d'accès

5.3 Validation des entrées

Toutes les données envoyées par le client sont potentiellement malveillantes. Il faut les
valider et les nettoyer avant utilisation.

❌ query = "SELECT * FROM users WHERE id = " + user_input

✅ [Link]("SELECT * FROM users WHERE id = ?", (user_input,))

5.4 Rate Limiting (Limitation des requêtes)

Pour protéger l'API contre les attaques par force brute et les DDoS, limiter le nombre de
requêtes par IP et par période.

Si requêtes > 100/minute → HTTP 429 Too Many Requests

5.5 Gestion des erreurs

Les messages d'erreur trop détaillés donnent des informations précieuses aux attaquants.
Les détails doivent être loggés côté serveur uniquement.

❌ { "error": "mysql://admin:password123@[Link]/db" }
✅ { "error": "Une erreur interne est survenue", "code": "ERR_500" }

5.6 Logging et Monitoring

Pour détecter les attaques en cours. Il faut logger toutes les tentatives de connexion
échouées, les accès sensibles, les requêtes suspectes, et utiliser des outils comme ELK
Stack ou Splunk.

5.7 Chiffrement des données sensibles

Module : Audit de Sécurité Informatique | Page 9

Sécurité des API REST — Rapport de Recherche

• Ne jamais stocker les mots de passe en clair (utiliser bcrypt ou Argon2)

• Chiffrer les données sensibles (numéros de carte, données médicales...)
• Ne jamais retourner des données sensibles inutiles dans les réponses

5.8 Versioning des APIs

Toujours désactiver les anciennes versions vulnérables dès qu'elles ne sont plus utilisées.

✅ [Link] (version actuelle)

❌ [Link] (à désactiver !)

5.9 CORS (Cross-Origin Resource Sharing)

Contrôler quels domaines ont le droit d'appeler l'API.

❌ Access-Control-Allow-Origin: *
✅ Access-Control-Allow-Origin: [Link]

Résumé des bonnes pratiques

Pratique Protection contre

HTTPS Man-in-the-Middle
JWT + Expiration Vol de session
Validation des entrées Injection SQL/NoSQL
Rate Limiting Force Brute, DDoS
Gestion des erreurs Fuite d'informations
Logging/Monitoring Détection d'attaques
Chiffrement Vol de données
Versioning APIs obsolètes vulnérables
CORS Requêtes non autorisées

Module : Audit de Sécurité Informatique | Page 10

Sécurité des API REST — Rapport de Recherche

6. Les outils d'audit de sécurité des API REST

6.1 Burp Suite

L'outil le plus utilisé par les professionnels de la cybersécurité. Il joue le rôle d'un proxy entre
le navigateur et le serveur pour intercepter et modifier les requêtes HTTP/HTTPS.

Fonctionnalités :
• Intercepter et modifier les requêtes en temps réel
• Scanner automatiquement les vulnérabilités
• Fuzzer les paramètres pour détecter les injections
• Bruteforcer les authentifications

Site officiel : [Link]

6.2 OWASP ZAP (Zed Attack Proxy)

L'alternative gratuite et open source à Burp Suite, développée par l'OWASP. Parfait pour
débuter dans l'audit de sécurité.

• Scanner automatique de vulnérabilités

• Tester les API REST via des fichiers OpenAPI/Swagger
• Générer des rapports détaillés

Site officiel : [Link]

6.3 Postman
Outil de test et de documentation des API, très utile pour l'audit de sécurité manuel. Permet
d'envoyer des requêtes personnalisées, tester les authentifications et automatiser des
séquences de tests.

Site officiel : [Link]

6.4 Nikto
Scanner de vulnérabilités open source qui analyse les serveurs web à la recherche de
mauvaises configurations, fichiers sensibles exposés et versions obsolètes de logiciels.

nikto -h [Link]

6.5 SQLMap
Outil spécialisé dans la détection et l'exploitation automatique des injections SQL. À utiliser
uniquement sur des systèmes autorisés.

sqlmap -u "[Link] --dbs

Module : Audit de Sécurité Informatique | Page 11

Sécurité des API REST — Rapport de Recherche

6.6 Wireshark
Analyseur de trafic réseau qui capture tous les paquets circulant sur le réseau. Permet de
vérifier que les communications sont bien chiffrées et de détecter des données sensibles
circulant en clair.

Comparaison des outils

Outil Type Gratuit Niveau

Burp Suite Proxy/Scanner Partiel Intermédiaire/Expert
OWASP ZAP Proxy/Scanner ✅ Oui Débutant/Intermédiaire
Postman Test API Partiel Débutant
Nikto Scanner ✅ Oui Débutant
SQLMap Injection SQL ✅ Oui Intermédiaire
Wireshark Analyse réseau ✅ Oui Intermédiaire

Module : Audit de Sécurité Informatique | Page 12

Sécurité des API REST — Rapport de Recherche

7. Conclusion

La sécurité des API REST est aujourd'hui un enjeu fondamental dans le domaine de la
cybersécurité. Avec l'explosion du nombre d'applications web et mobiles qui reposent sur
des API, les attaquants ont de plus en plus de cibles potentielles à exploiter.

À travers cette recherche, nous avons pu constater que les vulnérabilités des API REST
sont nombreuses et variées. De l'injection SQL aux failles d'authentification, en passant par
les problèmes d'autorisation et les mauvaises configurations, chaque aspect d'une API peut
devenir une porte d'entrée pour un attaquant si elle n'est pas correctement sécurisée.

L'OWASP API Security Top 10 reste la référence incontournable dans ce domaine. Les
exemples réels que nous avons vus — comme la faille de Capital One, la violation de
données de Venmo ou l'attaque DDoS contre Dyn — montrent que ces vulnérabilités ne
sont pas théoriques mais ont des conséquences réelles et graves.

La sécurisation d'une API REST repose sur plusieurs piliers complémentaires : une
authentification robuste (JWT, OAuth 2.0), la validation de toutes les entrées, le chiffrement
des communications via HTTPS, et la mise en place d'un monitoring avec une limitation des
requêtes.

En définitive, la sécurité des API REST n'est pas une option mais une nécessité absolue.
Elle doit être intégrée dès le début du développement selon le principe du Security by
Design — concevoir la sécurité dès le départ plutôt que de la rajouter après coup.

Module : Audit de Sécurité Informatique | Page 13

Sécurité des API REST — Rapport de Recherche

8. Références

• OWASP API Security Project : [Link]

• OWASP API Security Top 10 2023 :
[Link]
• PortSwigger (Burp Suite) : [Link]
• OWASP ZAP : [Link]
• SQLMap : [Link]
• Wireshark : [Link]
• Postman : [Link]

Module : Audit de Sécurité Informatique | Page 14