API Security Checklist

Checklist des points de sécurité les plus importants lors de la conception, du test et de la mise en production de votre API.

Authentification

Ne pas utiliser une authentification basique http (Basic Auth) mais plutôt un standard d'authentification.
Ne pas réinventer la roue lors de l'authentification, la génération de token, le stockage de mots de passe mais utiliser les standards.
Lors de l'authentification, mettre en place les fonctionnalités de bannissement (jail) avec des seuils de tentatives maximales (Max Retry).
Chiffrer toutes les données sensibles.

Accès

Limiter le nombre de requêtes (limitation de bande passante) pour éviter les dénis de service et les attaques par force brute.
Utiliser le protocole HTTPS côté serveur afin d'éviter les attaques de l'homme du milieu (MITM).
Utiliser les entêtes HSTS avec SSL pour éviter les attaques SSL Strip.
Désactiver les listes du répertoires.
Pour les API privées, n'autorisez l'accès qu'à partir d'adresses IP/hôtes sur liste blanche.

Autorisation

OAuth

Toujours valider la redirection d'uri (redirect_uri) côté serveur afin d'accéder uniquement aux URLs autorisées.
Toujours utiliser un échange de code plutôt que des tokens (ne pas autoriser response_type=token).
Utiliser le paramètre d'état (state) avec un hash aléatoire pour prévenir les CSRF sur le processus d'authentification OAuth.
Définir la portée par défaut et valider le paramètre de portée pour chaque application.

Entrées

Utiliser la bonne méthode en fonction de l'opération, GET (lire), POST (créer), PUT (remplacer/mettre à jour) et DELETE (pour supprimer un enregistrement).
Valider le content-type dans l'en-tête HTTP des requêtes (négociation de contenu) pour n'autoriser que les formats supportés (e.g. application/xml, application/json, etc…) et renvoyer une réponse 406 Not Acceptable si ça ne correspond pas.
Valider le content-type des données postées avec celles acceptées (e.g. application/x-www-form-urlencoded, multipart/form-data, application/json, etc…).

Traitement

Vérifier qu'aucun point d'entrée dans l'application n'échappe à l'authentification.
Éviter l'utilisation des identifiants de ressource utilisateur. Préférer /me/orders au lieu de /user/654321/orders
Ne pas utiliser d'identifiant auto-incrémenté mais plutôt des UUID.
Dans le cas du traitement de fichiers XML, être sûr que l'analyse des entités n'est pas activée par défaut afin d'éviter les failles XXE (XML external entity attack).
Dans le cas du traitement de fichiers XML, être sûr que l'expansion des entités n'est pas activée par défaut afin d'éviter les Billion Laughs/XML bomb (exponential entity expansion attack).
Utiliser les réseaux de diffusion de contenu (CDN) pour l'envoie de fichier.
Dans le cas du traitement d'importantes quantités de données, utiliser des Workers et des Queues pour retourner les réponses rapidement et éviter un blocage HTTP.
Ne pas oublier de désactiver le mode DEBUG.

Sorties

Envoyer l'en-tête X-Content-Type-Options: nosniff.
Envoyer l'en-tête X-Frame-Options: deny.
Envoyer l'en-tête Content-Security-Policy: default-src 'none'.
Supprimer les en-têtes d'empreinte - X-Powered-By, Server, X-AspNet-Version, etc…
Imposer le content-type des réponses, si la réponse est du application/json alors l'en-tête content-type est application/json.

CI & CD

Vérifiez votre conception et votre implémentation avec une couverture des tests unitaires et d'intégration.
Utilisez un processus de revue de code et ignorez l'auto-approbation.
Assurez-vous que tous les composants de vos services sont scannés par un logiciel anti-virus avant la mise en production, ainsi que les bibliothèques tierces et autres dépendances.
Exécutez en continu des tests de sécurité (analyse statique/dynamique) sur votre code.
Vérifiez vos dépendances (logiciel et système d'exploitation) pour les vulnérabilités connues.
Concevez une solution de rollback pour les déploiements.

Surveillance

Utilisez des connexions centralisées pour tous les services et composants.
Utilisez des agents pour surveiller tout le trafic, les erreurs, les requêtes, et les réponses.
Utilisez des alertes pour SMS, Slack, Email, Telegram, Kibana, Cloudwatch, etc.
Assurez-vous que vous n'enregistrez aucune donnée sensible comme les cartes de crédit, les mots de passe, les codes PIN, etc.
Utilisez un système IDS et/ou IPS pour surveiller vos requêtes et instances d'API.

Voir également :

yosriady/api-development-tools - Une collection de ressources utiles pour créer des API RESTful HTTP+JSON.
You don't need JWT, just use a randomly generated API key. If you need asymmetric encryption or tamper prevention, here are some alternatives to JWT.

API Security Best Practices (Advanced)

Rate Limiting & Abuse Prevention

Implement sliding window rate limiting per API key and IP.
Use exponential backoff for repeated failed authentication attempts.
Implement CAPTCHA or proof-of-work challenges after suspicious activity.
Monitor and alert on unusual API usage patterns (time, volume, endpoints).

GraphQL-Specific Security

Disable introspection in production environments.
Implement query depth limiting to prevent nested query attacks.
Use query cost analysis to prevent resource exhaustion.
Whitelist allowed queries in production when possible.

Secrets Management

Rotate API keys and secrets on a regular schedule.
Use hardware security modules (HSM) for signing operations.
Implement secret scanning in CI/CD pipelines.
Never commit secrets to version control - use environment variables or secret managers.

Zero Trust Architecture

Implement mutual TLS (mTLS) for service-to-service communication.
Validate all requests even from internal services.
Use short-lived tokens with automatic refresh.
Implement request signing for sensitive operations.

Contribution

N'hésitez pas à contribuer en forkant ce dépôt, faire quelques changements, et soumettre une pull request. Pour toute question, envoyez un courriel à [email protected].

API-Security-Checklist

Populaires