Fondamentaux

API et sécurité des API

Une API permet à des applications de communiquer entre elles. En cybersécurité, elle est souvent aussi importante que l'interface web, car elle expose directement des données, des actions et de la logique métier.


Ce qu'est une API

API signifie Application Programming Interface. C'est une interface prévue pour être utilisée par du code plutôt que directement par un humain.

Exemple simple :

Application front-end


      API


Base de données / service métier

Une API peut servir à :

  • récupérer un profil utilisateur
  • créer une commande
  • modifier un paramètre
  • envoyer un message
  • déclencher une action côté serveur

Formats courants

Les API web modernes utilisent souvent HTTP et JSON.

GET /api/users/42 HTTP/1.1
Host: example.com
Authorization: Bearer token

Réponse possible :

{
  "id": 42,
  "name": "Alice",
  "role": "user"
}

Autres formats ou styles fréquents :

  • REST
  • GraphQL
  • gRPC
  • SOAP dans des environnements plus anciens

Authentification et autorisation

Une API doit savoir qui appelle, puis ce que cet appelant a le droit de faire.

ContrôleQuestion
AuthentificationQui appelle l'API
AutorisationCette identité a-t-elle le droit
ValidationLes données reçues sont-elles acceptables
TraçabilitéL'action est-elle journalisée

La confusion entre authentification et autorisation est une cause fréquente d'incidents. Un utilisateur connecté ne doit pas pouvoir lire ou modifier les ressources d'un autre utilisateur sans droit explicite.


Risques fréquents

Les risques API les plus courants sont :

  • contrôle d'accès insuffisant
  • exposition excessive de données
  • absence de rate limiting
  • erreurs trop bavardes
  • tokens longs ou mal protégés
  • endpoints oubliés ou non documentés
  • validation insuffisante des entrées
  • droits trop larges côté base de données

Réflexe sécurité

Une API ne doit jamais faire confiance au front-end. Même si un bouton n'existe pas dans l'interface, l'endpoint peut parfois être appelé directement.


Rate limiting

Le rate limiting limite le nombre de requêtes dans un temps donné. Il protège contre certains abus, scans applicatifs, bruteforce et consommations excessives de ressources.

Exemples de zones sensibles :

  • connexion
  • inscription
  • réinitialisation de mot de passe
  • recherche
  • génération de fichiers
  • endpoints coûteux côté base

Un bon rate limiting tient compte du contexte : IP, compte utilisateur, clé API, route appelée et sensibilité de l'action.


Validation des données

Toutes les données reçues doivent être validées côté serveur.

À vérifier :

  • type attendu
  • taille maximale
  • format
  • valeurs autorisées
  • cohérence métier
  • droits sur la ressource ciblée

Une validation propre réduit les bugs, les injections, les erreurs serveur et les comportements inattendus.


Logs utiles

Une API doit produire des journaux exploitables sans exposer de secrets.

À journaliser :

  • route appelée
  • méthode HTTP
  • identifiant utilisateur si disponible
  • résultat de l'action
  • code HTTP
  • durée de traitement
  • erreurs importantes

À éviter dans les logs :

  • mots de passe
  • tokens complets
  • cookies de session
  • données personnelles inutiles
  • secrets applicatifs

Bons réflexes

  • documenter les endpoints
  • vérifier les droits côté serveur
  • limiter les données retournées
  • appliquer du rate limiting
  • valider toutes les entrées
  • utiliser HTTPS
  • journaliser les actions sensibles
  • séparer les clés et secrets par environnement
  • supprimer les endpoints inutiles

À retenir

Une API est une surface d'attaque à part entière. Elle doit être pensée comme une porte d'entrée directe vers les données et les actions métier.

Précédent
Certificats, PKI et TLS