Sécuriser une API REST : authentification, autorisations, limitation de débit et journalisation

Application mobile, portail client, logiciel métier, connecteur vers un partenaire, agent IA : tout passe désormais par des API. Et les API sont devenues une cible de choix, car elles exposent directement les données, souvent sans l’interface qui masquait les défauts. En avril 2026, la fuite de 11,7 millions de comptes de l’ANTS (France Titres) a rappelé l’enjeu ; plusieurs médias l’ont attribuée à une faille de contrôle d’accès permettant de consulter le dossier d’un autre usager en modifiant un identifiant, ce que les autorités n’ont pas détaillé publiquement. C’est précisément le risque numéro un des API selon l’OWASP. Voici les quatre piliers d’une API sûre.

L’essentiel en 30 secondes

• Authentification : jetons à durée de vie courte, validés strictement (signature, émetteur, audience, expiration).
• Autorisation : vérifier à chaque requête que l’utilisateur a le droit d’accéder à cet objet précis. C’est la faille la plus fréquente.
• Limitation de débit : quotas par utilisateur, par jeton et par adresse, pour bloquer l’aspiration de données et la force brute.
• Journalisation : qui a accédé à quoi, quand, avec quel résultat, sans jamais journaliser de secrets.

Les risques selon l’OWASP

Le Top 10 OWASP de la sécurité des API (édition 2023) reste la référence ; le Top 10 général 2025 a d’ailleurs élargi sa première catégorie, « contrôle d’accès défaillant », pour y inclure explicitement les défauts d’autorisation des API.

Pilier 1 : l’authentification

• Pour les utilisateurs, OAuth 2 / OpenID Connect avec un fournisseur d’identité, en suivant les bonnes pratiques consolidées par la RFC 9700 (janvier 2025) : flux avec PKCE, pas de flux implicite.
• Pour les échanges entre machines, des identifiants clients dédiés, ou une authentification par certificat (mTLS).
• Jetons d’accès courts (de quelques minutes à une heure), validation systématique de la signature, de l’algorithme attendu, de l’émetteur (iss), de l’audience (aud) et de l’expiration (exp).
• Jamais de clé ou de jeton dans l’URL : ils se retrouvent dans les journaux et l’historique.

Pilier 2 : l’autorisation, objet par objet

# Mauvais : on fait confiance à l'identifiant envoyé par le client
facture = factures.trouver(id=parametres["id"])

# Bon : la requête est filtrée par le propriétaire, à chaque appel
facture = factures.trouver(id=parametres["id"], client_id=utilisateur.client_id)
if facture is None:
    return reponse(404)

• Refus par défaut : toute route sans règle explicite est interdite.
• Des identifiants non devinables (UUID) compliquent l’énumération mais ne remplacent pas la vérification.
• Ne renvoyez que les champs nécessaires et acceptez uniquement les champs modifiables (liste explicite) pour éviter l’affectation de masse.
• Écrivez des tests automatisés d’autorisation : « l’utilisateur A ne peut pas lire, modifier ou supprimer les objets de B ».

Pilier 3 : la limitation de débit

Elle protège contre la force brute, l’aspiration de données et les abus de coût. Exemple avec Nginx en frontal :

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
        proxy_pass http://application;
    }
}

Complétez par des quotas par utilisateur ou par jeton dans l’application ou la passerelle d’API, des limites plus strictes sur les routes sensibles (connexion, réinitialisation de mot de passe, export), une taille maximale de page et de corps de requête. Des outils comme CrowdSec peuvent bloquer automatiquement les sources abusives.

Pilier 4 : la journalisation

• Pour chaque requête : horodatage, identité (utilisateur ou client), route, identifiant de l’objet, code de réponse, adresse source, identifiant de corrélation.
• Jamais de mots de passe, jetons, numéros de carte ou données de santé dans les journaux.
• Alertes sur les signaux d’abus : nombreuses réponses 403 ou 404 pour un même utilisateur (énumération), volumes anormaux, accès hors horaires.
• Conservation et protection des journaux, avec centralisation.

Et aussi

• Inventaire à jour des API et versions, avec une spécification OpenAPI ; décommissionnement des anciennes versions.
• Validation des entrées par schéma, rejet des champs inconnus.
• TLS partout, en-têtes de sécurité et CORS restreint aux origines connues.
• Messages d’erreur génériques côté client, détails uniquement dans les journaux.
• Tests de sécurité dans le cycle de développement : voir SAST, DAST et SCA.

Questions fréquentes

Une clé d’API suffit-elle ?

Pour identifier une application cliente, éventuellement. Pas pour identifier un utilisateur ni porter ses droits : il faut alors un jeton lié à l’utilisateur.

Une passerelle d’API règle-t-elle tout ?

Elle centralise authentification, limitation et journalisation, ce qui est précieux. Mais l’autorisation objet par objet reste dans le code métier : la passerelle ne sait pas à qui appartient la facture 1042.

Comment tester une API existante ?

Avec deux comptes de test, essayez d’accéder aux objets de l’un avec le jeton de l’autre, sur chaque route. C’est simple, et cela révèle la faille la plus courante.

Les API internes doivent-elles être sécurisées de la même façon ?

Oui : un attaquant entré dans le réseau, ou un agent IA mal encadré, les utilisera. Voir les risques des agents IA.

Sources

• OWASP, API Security Top 10 2023.
• OWASP, Top 10 2025.
• IETF, RFC 9700 : bonnes pratiques de sécurité OAuth 2.0, janvier 2025.
• Journal du Geek, piratage de l’ANTS, 4 mai 2026.

Besoin d’un accompagnement ?

MPCÂBLE Solutions Informatiques (MPCSI) accompagne particuliers, entreprises, associations et collectivités depuis Gaudiès, en Ariège : sur site en Occitanie, principalement dans un rayon de 40 km (Pamiers, Foix, Mirepoix, Saverdun, Castelnaudary), et à distance partout en France. Nous auditons la sécurité de vos applications web et API lors d’un audit. Demandez un devis gratuit ou appelez le 05 32 42 99 98.