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ôle | Question |
|---|---|
| Authentification | Qui appelle l'API |
| Autorisation | Cette identité a-t-elle le droit |
| Validation | Les 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.
