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.

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.

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.

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…).
Valider les entrées utilisateur pour éviter les vulnérabilités classiques (e.g. XSS, SQL-Injection, Remote Code Execution, etc…).
N'utiliser aucune donnée sensible (identifiants, mots de passe, tokens de sécurité, ou clés d'API) dans l'URL, mais utiliser les en-têtes d'autorisations standards.
Utiliser uniquement le chiffrement côté serveur.
Utiliser un service de passerelle d'API afin d'obtenir la mise en cache, une limitation de la saturation des ressources, la gestion des pics d'activités et le déploiement automatique des ressources.

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.
Utiliser des piles non exécutables lorsqu'elles sont disponibles.

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.
Do not return overly specific error messages to the client that could reveal implementation details, use generic messages instead, and log detailed information only on the server side.
Ne pas retourner de données sensibles dans les réponses identifiants, mots de passe, tokens de sécurité.
Retourner un code de statuts en adéquation avec l'opération effectuée. (e.g. 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, etc…).