## Introduction Les API sont aujourd’hui le tissu conjonctif des systèmes modernes : elles alimentent applications web et mobiles, intégrations et microservices. Cette omniprésence en fait aussi l’une des plus grandes surfaces d’attaque de votre pile. Tout point de terminaison joignable depuis Internet (ou un réseau interne plat) sera exploré par des scanners, des bots et des humains. Un seul maillon faible peut exposer des données, des clés ou le contrôle complet de votre environnement. La sécurité côté frontend ne protège jamais votre API. Le code côté client s’exécute sur des appareils que vous ne contrôlez pas, peut être modifié et ne peut pas garder de secrets. Traitez chaque appel d’API comme s’il venait d’un environnement non fiable. Le durcissement de la sécurité des API REST exige une défense en profondeur. Aucun contrôle unique (p. ex. JWT, limiteur de débit, ou WAF) n’arrêtera toutes les attaques. Vous avez besoin de protections superposées et indépendantes afin que, si l’une échoue, une autre intercepte le problème. L’objectif est de rendre l’exploitation difficile, bruyante et rapidement récupérable. Un chemin de requête typique en production ressemble à ceci : Client ↓ Internet ↓ WAF / CDN ↓ API Gateway ↓ Authentication ↓ Authorization ↓ Validation ↓ Business Logic ↓ Database Chaque couche offre un type de contrôle différent : filtrage, identification, vérification des permissions, assainissement et gestion sûre des données. Le reste de ce guide décrit une approche de niveau production pour durcir la sécurité d’une API REST avec des exemples pratiques, des attaques réalistes et des défenses actionnables. --- ## 1) Modèle de menaces Toutes les API n’ont pas le même profil de risque. Votre conception de sécurité doit correspondre à votre exposition et à la sensibilité de vos données. - API publiques : Exposées à Internet; supposez une découverte et des abus automatisés constants. Objectifs courants : scraping de données, prise de contrôle de comptes, amplification de coûts (DoS) et credential stuffing. - API partenaires : Restreintes à des partenaires connus, mais traversant des frontières organisationnelles. Risques : fuites de clés, partenaires sur‑privilégiés, surveillance insuffisante des anomalies d’usage. - API internes : Utilisées par des équipes et services internes. Souvent trop fiables. Risques : mouvements latéraux après compromission initiale, identifiants divulgués dans les journaux CI, environnements dev/test partagés. - Microservices : De nombreuses petites API internes. Risques : usurpation service‑à‑service, absence d’autorisation entre services, chaînes de dépendances complexes. - API machine‑à‑machine : Clients sans interface (jobs, services, IoT). Risques : identifiants longue durée, rotation faible, mTLS faible, rejouabilité. - API mobiles : Utilisées par des apps mobiles. L’app n’est pas une frontière de confiance; les attaquants peuvent instrumenter, proxyfier et rétro‑concevoir les appels. Les objectifs des attaquants incluent souvent : exploiter l’accès au niveau objet (IDOR/BOLA), élever les privilèges, extraire massivement des données (exposition excessive), abuser de la logique métier (abus de coupons, fraude de parrainage) et pivoter vers l’infrastructure en volant des secrets. --- ## 2) Authentification L’authentification prouve qui (ou quoi) appelle. Le bon choix dépend du type de client, de la tolérance au risque et de la complexité opérationnelle. ### Méthodes courantes - API Keys : Jetons statiques simples identifiant un appelant. - Basic Authentication : HTTP Basic avec nom d’utilisateur:mot de passe. - Bearer Tokens : Jetons opaques (chaînes aléatoires) présentés dans l’en‑tête Authorization. - JWT (JSON Web Tokens) : Jetons auto‑contenus avec des claims, signés (parfois chiffrés). - OAuth 2.0 : Cadre d’autorisation déléguée; prend en charge serveur‑à‑serveur et consentement utilisateur. - OpenID Connect (OIDC) : Couche d’identité au‑dessus d’OAuth 2.0 pour l’authentification utilisateur. - mTLS (Mutual TLS) : Le client présente un certificat X.509; le serveur valide le certificat et le mappe à une identité. - Comptes de service : Identités non humaines pour l’automatisation/services; souvent avec OAuth client credentials ou mTLS. - Client Credentials (OAuth 2.0) : Émission de jetons machine‑à‑machine pour comptes de service. ### Choisir une méthode
MéthodeAtoutsFaiblessesIdéal pour
API KeyFaciles à émettre/révoquer; simplesPas de contexte utilisateur; fuites possibles; difficile à bornerAccès service basique, prototypes
Basic AuthSupport universelSecret réutilisable transmis; non borné; rotation ardueRarement recommandé en production
Bearer (opaque)Stockable côté serveur; révocation aiséeNécessite une introspection centraliséePasserelles, sessions courte durée
JWTClaims auto‑contenus; sans état; bien pour l’échelleRévocation difficile; écueils de signature; tailleWeb/mobile avec TTL court + refresh
OAuth 2.0Flux standardisés; scopes; délégationComplexité; risques de mauvaise configIntégrations tierces, API partenaires
OIDCIdentité utilisateur vérifiable; claims standardExige validation correcte d’audience/émetteurConnexion utilisateur web/mobile
mTLSPreuve de possession forte; pas de secret partagéGestion PKI; distribution de certifs clientService‑à‑service, partenaires de confiance
Client CredentialsJetons serveur automatisés; scopesPas d’identité utilisateur; secret client à protégerAppels machine‑à‑machine
Conseils pratiques : - Pour les apps orientées utilisateur : OIDC (Authorization Code avec PKCE) émettant des JWT d’accès à courte durée et des refresh tokens opaques. - Pour serveur‑à‑serveur : OAuth 2.0 Client Credentials ou mTLS (souvent les deux), avec scopes étroits et TTL courts. - Pour partenaires : OAuth 2.0 avec scopes fins et allowlists d’IP ou mTLS. - Évitez Basic Auth et les API keys longue durée autant que possible. Dépannage : - Si les jetons échouent seulement en production, vérifiez l’audience (aud), l’émetteur (iss) et la gestion du décalage d’horloge. - Si la poignée de main mTLS échoue, validez la chaîne de confiance CA, les entrées SAN et que le proxy/passerelle relaie correctement le certificat du pair. --- ## 3) Autorisation L’authentification répond à « qui êtes‑vous ? ». L’autorisation répond à « que pouvez‑vous faire ? ». Ne confondez jamais authentification et permission. Concepts clés : - Propriété des ressources : Qui possède ou peut accéder à un objet (p. ex., un utilisateur ne lit que ses propres factures). - RBAC (Role‑Based Access Control) : Des rôles (admin, support, user) accordent des permissions. - ABAC (Attribute‑Based Access Control) : Décisions fondées sur des attributs (locataire, département, confiance du device, région, horaire). - Scopes : Permissions grossières associées aux jetons (p. ex., payments:read, payments:write). - Claims : Données de jeton (sub, tenant, rôles) utilisées pour décider. - Politiques : Règles centralisées, souvent exprimées dans un langage de politique (p. ex., OPA/Rego) ou en code. Implémentez des contrôles d’autorisation sur chaque endpoint et chaque accès objet. Exemples : - Faire respecter l’isolation de locataire dans toutes les requêtes de données. - Valider la propriété pour les IDs d’objets dans le chemin et le corps (pas seulement la présence d’un jeton). - Principe du moindre privilège : un jeton en lecture seule ne peut jamais écrire, même s’il est authentifié. --- ## 4) OWASP API Security Top 10 (avec exemples) - Broken Object Level Authorization (BOLA) - Quoi : Contrôles manquants sur la propriété d’objets ou les frontières de locataire. - Exemple d’attaque : GET /v1/users/12345 avec un jeton pour l’utilisateur 67890 retourne les données de 12345. - Prévenir : Toujours filtrer par propriétaire/locataire au niveau données (p. ex., WHERE id = :id AND tenant_id = :tenant), ne vous fiez pas uniquement aux IDs venant du client. - Broken Authentication - Quoi : Authentification faible ou mal configurée permettant la prise de compte ou l’abus de jetons. - Exemple : Jetons longue durée ou API keys prévisibles; PKCE manquant dans les apps mobiles. - Prévenir : Mots de passe forts et MFA (si pertinent), TTL courts, PKCE pour clients publics, rotation des secrets, stockage sécurisé des jetons. - Broken Function Level Authorization (BFLA) - Quoi : Des utilisateurs accèdent à des actions admin ou privilégiées. - Exemple : Un rôle support appelle POST /v1/admin/ban-user. - Prévenir : Vérifier rôle et scope au niveau de la route et dans la logique métier. - Exposition excessive de données - Quoi : L’API renvoie plus de champs que nécessaire; le client filtre côté frontend. - Exemple : Retourner password_hash, ssn ou des indicateurs internes dans les réponses. - Prévenir : Projection côté serveur; liste blanche de champs; filtrage de sortie selon le rôle et l’usage. - Mauvaise configuration de sécurité - Quoi : Identifiants par défaut, consoles admin ouvertes, en‑têtes manquants, debug activé en prod. - Exemple : Endpoints /actuator ouverts; CORS sur * avec credentials=true. - Prévenir : Durcir les frameworks, désactiver le debug, appliquer les en‑têtes de sécurité, verrouiller les surfaces admin. - Injection (SQL/NoSQL/commande) - Quoi : Entrées non fiables altèrent des requêtes ou commandes. - Exemple : Un paramètre de filtre REST alimente une clause SQL brute; transfert non sécurisé vers un shell. - Prévenir : Requêtes paramétrées, garde‑fous ORM, wrappers de commande sûrs, validation stricte des entrées. - Gestion d’inventaire inadéquate - Quoi : Endpoints inconnus, non suivis ou non documentés encore exposés. - Exemple : Ancien /v0 présent et non surveillé. - Prévenir : Tenir un catalogue d’API, automatiser la découverte via passerelles et code, déclasser les versions obsolètes. - Affectation massive (Mass Assignment) - Quoi : Les champs fournis par le client mappent directement aux propriétés du modèle. - Exemple : PATCH /v1/users/me définit role=admin. - Prévenir : Listes d’autorisation pour champs modifiables; ignorer ou rejeter les champs inconnus. - Server‑Side Request Forgery (SSRF) - Quoi : L’API récupère une URL fournie par le client; l’attaquant pivote vers le réseau interne. - Exemple : POST /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials. - Prévenir : Refuser IP privées et IP metadata, valider DNS et IP, proxy egress avec allowlists. - Consommation non sécurisée d’API - Quoi : Faire confiance à des API amont sans validation ni limites. - Exemple : Accepter aveuglément des assertions d’identité d’une API partenaire. - Prévenir : Valider les réponses amont, appliquer des schémas, limiter le débit entrant/sortant, imposer timeouts et coupe‑circuits. --- ## 5) Sécurité du transport - HTTPS partout : Rediriger HTTP vers HTTPS; pas de contenu mixte. - Versions TLS : Privilégier TLS 1.2+; désactiver TLS 1.0/1.1. - Suites de chiffrement : Privilégier les AEAD modernes (p. ex., TLS_AES_128_GCM_SHA256, ECDHE+AES‑GCM); désactiver l’héritage. - HSTS : Imposer HTTPS avec un max‑age long, includeSubDomains, preload (après validation prudente). - Rotation de certificats : Automatiser via ACME (Let’s Encrypt) ou certificats managés cloud; surveiller l’expiration. - mTLS : Utiliser pour service‑à‑service et partenaires de haute confiance; lier les certifs aux identités. - Certificate pinning : Envisager seulement pour des clients contrôlés; prévoir la rotation des pins. - Proxies inverses et passerelles : Terminer TLS en périphérie; re‑chiffrer vers l’amont ou imposer mTLS en interne. Exemple d’en‑têtes sécurisés : Strict-Transport-Security: max-age=31536000; includeSubDomains; preload X-Content-Type-Options: nosniff X-Frame-Options: DENY Referrer-Policy: no-referrer Dépannage : Si les clients voient des erreurs de poignée de main après un déploiement, vérifiez le chevauchement des suites de chiffrement, la configuration SNI et les protocoles ALPN avec HTTP/2. --- ## 6) Validation des entrées Validez avant usage. Préférez les listes blanches et les schémas aux vérifications ad hoc. - Listes d’autorisation : Énumérer types, formats et plages autorisés. - Validation JSON : Imposer un schéma JSON pour les corps. Rejeter les champs inconnus si pertinent. - Validation OpenAPI : Utiliser la passerelle ou un middleware pour valider requêtes et réponses contre votre spec OpenAPI. - Tailles maximales : Limiter la taille du corps (p. ex., 1–5 Mo) et la longueur des champs pour éviter la pression mémoire et les abus. - Validation Content‑Type : Exiger application/json pour JSON; rejeter les incohérences. - Défenses contre l’injection : Requêtes préparées; assainir/encoder si nécessaire; ne jamais construire des requêtes depuis des entrées brutes. - Traversée de répertoires : Normaliser et restreindre les chemins; ne pas exposer des chemins fichiers bruts. - Attaques du parseur JSON : Limiter la profondeur d’imbrication et le nombre total de clés; rejeter les clés dupliquées si le parseur du langage est ambigu. - ReDoS (RegExp) : Éviter le backtracking catastrophique; tester les regex pour la performance. Exemple (Node/Express avec AJV) : import Ajv from "ajv"; const ajv = new Ajv({allErrors: true, removeAdditional: "failing"}); const schema = { type: "object", additionalProperties: false, properties: { email: {type: "string", format: "email", maxLength: 254}, age: {type: "integer", minimum: 13, maximum: 130} }, required: ["email"] }; function validate(schema) { const validateFn = ajv.compile(schema); return (req, res, next) => { if (!validateFn(req.body)) { return res.status(422).json({error: "invalid_request", details: validateFn.errors}); } next(); }; } --- ## 7) Durcissement des sorties - Réponses minimales : Ne retourner que les champs requis par le client. - Filtrage des données : Projeter les champs au niveau base de données ou sérialisation. - Autorisation par champ : Champs sensibles (p. ex., ssn_last4) soumis à des règles/ rôles. - Pagination : Plafonner la taille de page (p. ex., max 100) pour éviter le scraping de masse. - Gestion des erreurs : Messages génériques et stables côté client; journaliser les détails en interne. - Fuites d’information : Retirer traces de pile, bannières de framework, IDs de build. - Endpoints de debug : Désactiver ou protéger en production; ne jamais exposer une santé avec détails sensibles. - En‑têtes version/serveur : Éviter de divulguer les versions; utiliser un en‑tête Server neutre. Exemple de réponse d’erreur : { "error": "forbidden", "error_description": "You do not have access to this resource.", "request_id": "c02f1f6a-..." } --- ## 8) Sécurité JWT - Signature : Utiliser des clés asymétriques fortes (RS256/ES256). Éviter none et HS256 avec secrets faibles. - Expiration : TTL court pour les access tokens (5–15 min). Utiliser des refresh tokens avec rotation et détection de réutilisation. - Audience et émetteur : Vérifier que aud correspond à votre API et iss à votre IdP. - Rotation de clés : Faire tourner régulièrement; exposer un endpoint JWKS; mettre en cache selon kid. - Confusion d’algorithme : Imposer l’algorithme attendu; ne jamais faire confiance au header alg seul. - Rejeu de jeton : Lier les jetons au contexte client si possible; maintenir un jti ou une version de session pour invalider. - Révocation : Conserver une denylist côté serveur pour les révocations critiques ou combiner TTL courts et rotation de refresh. Erreurs fréquentes : - Mettre des données sensibles (mots de passe, secrets) dans les claims JWT. - Accepter des jetons expirés à cause d’un mauvais réglage d’horloge. - Ne pas valider correctement nbf/iat. --- ## 9) Limitation de débit Implémentez des limites de débit pour réduire les abus et protéger la capacité. - Dimensions : Par IP, par utilisateur, par API key, par locataire et par endpoint. - Algorithmes : Fenêtre fixe, fenêtre glissante, token bucket, leaky bucket. - Rafales : Autoriser de courtes pointes, soutenir un débit moyen plus faible. - Limites adaptatives : Durcir face à une activité suspecte (credential stuffing, pics d’erreurs). - Limitation distribuée : Coordonner les compteurs via Redis ou des fonctions de passerelle entre réplicas et régions. Pourquoi insuffisant seul : Les attaquants font tourner les IP, distribuent la charge ou s’ajustent sous les seuils. Associez limites, authentification, détection comportementale et alertes d’anomalies. --- ## 10) API Gateway Les passerelles centralisent les préoccupations transversales : - Authentification : Vérifier tokens OAuth/OIDC; validation de clés; terminaison mTLS. - Autorisation : Imposer des scopes et politiques grossières; transmettre l’identité aux services. - Routage et transformation : Routage par chemin; normaliser les en‑têtes; transformations JSON/XML. - Journalisation : Logs d’accès structurés avec IDs de corrélation. - Limitation de débit : Par clé/utilisateur/IP avec compteurs distribués. - Validation des requêtes : Appliquer les schémas OpenAPI; rejeter les méthodes inconnues. - Coupe‑circuits : Réduire la charge et isoler les backends défaillants. - Caching : Mettre en cache les GET sûrs avec ETags. Utile mais insuffisant : L’autorisation fine et la validation métier restent dans vos services. Toujours re‑valider la confiance à chaque saut (Zero Trust). --- ## 11) CORS CORS contrôle quelles applications web (navigateurs) peuvent lire les réponses de votre API. Ce n’est pas de l’authentification. Éléments clés : - Origines : N’autoriser que des origines connues (https://app.example.com). Éviter les jokers avec credentials. - Identifiants : Si vous utilisez cookies ou en‑têtes d’auth, définissez Access-Control-Allow-Credentials: true et spécifiez des origines exactes. - Pré‑requête (OPTIONS) : Gérer Access-Control-Request-Method et -Headers; répondre avec méthodes/en‑têtes autorisés. - Jokers : Acceptables seulement pour des API publiques, anonymes, sans credentials. Erreurs courantes : - Mettre Access-Control-Allow-Origin: * avec credentials; les navigateurs refuseront et les diagnostics seront confus. - Autoriser trop largement tous en‑têtes/méthodes; restreindre à ce que vous utilisez réellement. --- ## 12) Gestion sécurisée des erreurs Mauvais exemples : - Erreurs base de données : "SQLSTATE[42S22]: Column not found: 1054 Unknown column 'role' in 'field list'" - Traces de pile : "NullPointerException at com.example.UserService..." - Messages SQL : "syntax error at or near 'DROP'" - Exceptions de framework : Pages debug verbeuses montrant des variables d’environnement. Réponses sécurisées : - Au client : 500 Internal Server Error avec un message générique et un request_id. - Aux journaux : Trace complète, paramètres (nettoyés des secrets) et métadonnées de corrélation. --- ## 13) Journalisation Journalisez ce qui compte, et rien que vous ne pouvez protéger. - Logs d’audit : Événements liés à la sécurité (connexion, déconnexion, émission/révocation de jetons, changements de permissions, export de données, actions admin). - Logs d’authentification : Succès/échec, MFA, raisons d’échec. - Échecs d’autorisation : Ressource, acteur, décision et politique ayant refusé l’accès. - Masquage de données sensibles : Ne jamais journaliser mots de passe, jetons, cartes complètes ou secrets. - IDs de corrélation : Générer un request_id en périphérie; propager via en‑têtes (p. ex., X-Request-ID, traceparent). - Événements de sécurité : Émettre du JSON structuré pour ingestion SIEM. --- ## 14) Supervision Détectez les abus tôt. - Brute force et credential stuffing : Surveiller les échecs de connexion et motifs IP/user‑agent inhabituels. - Abus d’API : Taux d’erreur élevés, endpoints inhabituels, motifs de scraping, ou pagination au plafond. - Détection d’anomalies : Anomalies géographiques, déviations horaires, pics soudains sur endpoints sensibles. - Violations de rate limit : Alerter sur des 429 répétés par la même identité ou plages d’IP. - Tentatives d’élévation de privilèges : Accès refusés répétés vers routes admin depuis des comptes non admin. --- ## 15) Gestion des secrets - Variables d’environnement : À accepter seulement à l’exécution; ne jamais les committer; portée en moindre privilège. - Coffres/gestionnaires : HashiCorp Vault, AWS Secrets Manager, Azure Key Vault ou GCP Secret Manager pour rotation et contrôle d’accès. - Rotation : Faire tourner régulièrement API keys, mots de passe DB et clés de signature; automatiser si possible. - Chiffrement au repos : Protéger secrets en transit et au repos; restreindre les rôles IAM à la récupération. - Environnements séparés : Secrets distincts par env; ne pas partager dev/test/prod. Ne stockez jamais de secrets dans Git, les journaux CI ou les images de conteneur. --- ## 16) Versionnage d’API - Version dans l’URI : /v1/resource; le plus simple pour router et mettre en cache. - Version dans les en‑têtes : Accept-Version ou media types personnalisés; URLs plus propres, mais plus d’outillage. - Dépréciation : Annoncer les délais; fournir une supervision de l’usage des versions obsolètes. - Rétro‑compatibilité : Ajouter des champs, ne pas en retirer; pas de breaking change sans nouvelle version. - Impacts sécurité : Les anciennes versions manquent souvent de correctifs; suivez les versions dans votre inventaire et retirez vite l’insupporté. --- ## 17) Microservices et API Zero Trust - Authentification service‑à‑service : Jetons courte durée (OAuth Client Credentials) ou mTLS avec identités SPIFFE. - mTLS partout : Chiffrer et authentifier le trafic est‑ouest; vérifier les certifs à chaque saut. - SPIFFE/SPIRE : Délivrer dynamiquement des identités et certificats de workloads. - Service Mesh : Istio/Linkerd fournissent mTLS, politique et télémétrie cohérentes. - Autorisation interne : N’assumez jamais que « interne = fiable »; appliquer des politiques à chaque appel interne. Principe Zero Trust : Toujours vérifier, ne jamais faire confiance par défaut, et accorder le strict nécessaire. --- ## 18) Liste de durcissement pour la production (contrôles) - Moindre privilège : Rôles IAM, utilisateurs DB et comptes de service strictement bornés. - En‑têtes de sécurité : HSTS, X-Content-Type-Options, X-Frame-Options, CSP si pertinent pour docs/portail API. - Timeouts : Côté client, passerelle et backend pour échouer vite et libérer des ressources. - Limites de charge utile : Limiter taille requête/réponse; compresser avec prudence (voir ci‑après). - Limites de connexions : Protéger pools amont et nombres de threads. - Compression : Désactiver sur endpoints très sensibles avec secrets pour réduire BREACH/CRIME; sinon paramètres sûrs. - Cache : Vérifier que les réponses sensibles ne sont pas en cache public. - Méthodes HTTP : N’activer que ce que vous utilisez; exiger des idempotency keys pour certains POST. - OPTIONS/TRACE : Implémenter OPTIONS pour CORS; désactiver TRACE. - PUT/DELETE : Imposer autorisation et idempotence pour les méthodes modifiant l’état. - Protection contre le rejeu : Utiliser idempotency keys, horodatages et nonces pour opérations critiques. --- ## 19) Architecture sécurisée de bout en bout Un système SaaS réaliste pourrait être : Client (Web/Mobile) ↓ CDN (TLS, caching statique) ↓ WAF (signatures + détection d’anomalies) ↓ API Gateway (mTLS de la périphérie → services, validation OAuth/OIDC, rate limits, validation de schéma) ↓ Service d’authentification (fournisseur OIDC, émission de jetons, JWKS) ↓ Moteur de politiques d’autorisation (OPA ou politiques au niveau service) ↓ Services d’API REST (filtrage entrée/sortie, logique métier) ↓ Base de données (sécurité au niveau ligne, moindre privilège) ↓ Logs d’audit (stockage immuable) ↓ Supervision/Alerte → SIEM (corrélation et détection) Déroulé : - Le client envoie une requête avec Authorization: Bearer . - Le WAF bloque signatures connues et anomalies. - La passerelle valide TLS, vérifie le JWT (iss, aud, exp, sig), applique des scopes grossiers et des limites de débit, et valide le schéma de charge utile. - Le service extrait les claims et interroge le moteur d’autorisation avec sujet, action, ressource et contexte. - Le service applique la validation d’entrée, exécute la logique métier et interroge la DB avec contraintes locataire/propriétaire. - La réponse est réduite aux champs minimaux; les erreurs sont normalisées avec request_id. - Événements d’audit et métriques sont écrits; le SIEM corrèle des anomalies à travers les logs. --- ## 20) Scénarios d’attaque pratiques - IDOR/BOLA - Attaque : L’attaquant itère des IDs dans GET /v1/users/{id} et récupère des profils inter‑locataires. - Défense : Appliquer le scoping propriétaire/locataire dans les requêtes; tester avec des tests d’autorisation automatisés par endpoint. - Rejeu de JWT - Attaque : Un jeton volé sur un device compromis est réutilisé. - Défense : TTL court, liaison du jeton au client ou à l’état de session, suivi jti, rotation de refresh avec détection de réutilisation. - Jeton expiré - Attaque : Le client réessaie avec un jeton expiré; si le décalage d’horloge serveur est grand ou l’expiration ignorée, il peut être accepté. - Défense : Appliquer strictement exp; tolérer un faible décalage (±60 s); retourner 401 avec WWW-Authenticate; surveiller les échecs exp répétés. - Escalade de privilèges - Attaque : Un utilisateur rôle support appelle des endpoints admin sans contrôles explicites. - Défense : Protéger les endpoints par rôles + politiques; vérifier scopes; écrire des tests négatifs pour non‑admins. - Injection SQL - Attaque : Un paramètre de filtre injecte OR 1=1 pour vider des données. - Défense : Requêtes paramétrées; rejeter les expressions de filtre arbitraires; schémas d’entrée. - Affectation massive - Attaque : PATCH /v1/users/me avec {"role":"admin"} s’auto‑promouvoit. - Défense : Listes d’autorisation de champs; ignorer/rejeter les champs inconnus; imposer les changements de rôle via un flux distinct et privilégié. - Contournement de rate limit - Attaque : Requêtes distribuées depuis de nombreuses IP restent sous les limites par IP. - Défense : Limites par identité et par locataire; détection comportementale; CAPTCHA ou défi renforcé si pertinent. --- ## 21) Tester la sécurité des API - Postman : Collections avec flux d’auth, variables d’environnement et scripts de test. - curl : Idéal pour des exemples reproductibles et des tests de fumée en CI. - OWASP ZAP : Scan actif/passif; automatiser avec des scans de base. - Burp Suite : Tests manuels, repeater, intruder, et OAST pour SSRF. - Validation OpenAPI : Tests de contrat pour aligner serveurs et clients sur les schémas. - Tests de sécurité automatisés : Tests unitaires/intégration pour décisions d’authZ; tests négatifs pour chemins interdits. - Fuzz testing : Charges utiles aléatoires pour parseurs/validateurs; surveiller crashs/timeouts. - Tests AuthN/AuthZ : Tests explicites de chaque couple endpoint‑méthode, tous rôles et locataires. --- ## 22) Erreurs de production courantes - Faire confiance à la validation frontend : Toujours valider côté serveur. - Se contenter de l’authentification : Manquer l’autorisation sur objets et fonctions. - Trop de données retournées : Champs excessifs ou endpoints bulk sans pagination. - Journaliser mots de passe/jetons : Les secrets finissent dans les logs et outils en aval. - Secrets JWT faibles : HS256 avec clés devinables ou valeurs par défaut d’env. - Charges utiles illimitées : Des JSON énormes épuisent la mémoire. - Reprises illimitées : Brute force permis par des politiques laxistes. - Aucune supervision : Les attaques passent inaperçues jusqu’à la brèche. - Pas de rotation : Clés longue durée; identifiants obsolètes après départs. - Inventaire d’API ignoré : Endpoints et versions oubliés persistent. --- ## 23) REST vs GraphQL vs gRPC (point de vue sécurité) - REST - Avantages : Simple, compatible cache, outillage mature, autorisation claire par ressource. - Inconvénients : Beaucoup d’endpoints à gérer; risques de sur/sous‑récupération. - GraphQL - Avantages : Requêtes flexibles; sélection pilotée client réduit la sur‑récupération. - Inconvénients : Autorisation complexe par champ; contrôle du coût de requête requis; exposition d’introspection; limites de profondeur/complexité nécessaires. - gRPC - Avantages : Fortement typé; rapide; idéal service‑à‑service avec mTLS. - Inconvénients : Support navigateur via passerelles; moins lisible humainement; imposer authZ par méthode/message. Préoccupations opérationnelles : Appliquez les mêmes principes — authentification, autorisation, validation, limitation de débit, journalisation — adaptés aux spécificités du protocole. --- ## 24) Liste finale de durcissement - Inventaire : Cataloguer toutes les API, versions et propriétaires. - TLS : Imposer TLS 1.2+; HSTS; renouvellements de certificats automatisés. - AuthN : OIDC pour utilisateurs; OAuth 2.0 Client Credentials ou mTLS pour services; jetons courte durée. - AuthZ : RBAC/ABAC à chaque endpoint; tester rigoureusement BOLA/BFLA. - Entrées : Validation basée sur OpenAPI; types de contenu stricts; limites de taille. - Sorties : Champs minimaux; autorisation par champ; erreurs génériques et stables. - JWT : Vérifier iss/aud/exp; rotation des clés; JWKS et rotation des refresh tokens. - Limites de débit : Par IP/utilisateur/clé/locataire; compteurs distribués; throttling adaptatif. - Passerelle : AuthN centralisée, validation de schéma, logs et coupe‑circuits. - CORS : Origines exactes; gestion sûre des credentials; pré‑requêtes correctes. - Logs : Structurés, masqués, corrélés; audit d’événements clés; intégration SIEM. - Supervision : Alertes sur échecs d’auth, anomalies et motifs d’abus. - Secrets : Gestionnaire dédié; rotation; pas de secrets dans Git ni images. - Versionnage : Déprécier les anciennes versions; télémétrie d’usage; retrait en temps voulu. - Microservices : mTLS, SPIFFE, moteur de politiques; Zero Trust. - Hygiène de prod : Timeouts, limites de connexions et de charge utile, règles de compression, idempotence et protection anti‑rejeu. --- ## Conclusion Le durcissement de la sécurité d’une API REST est une discipline par couches, pas une case à cocher. Les contrôles frontend ne protègent pas votre API; chaque requête doit être authentifiée, autorisée, validée et contrainte par conception. Mettez en place une sécurité de transport robuste, une authentification fiable, une autorisation fine, des contrôles d’entrée/sortie stricts, et des garde‑fous opérationnels comme la limitation de débit, la journalisation et la supervision. Attendez‑vous à des attaques, détectez‑les rapidement et concevez vos systèmes pour échouer en sécurité. Intégrez la sécurité à votre API dès la première route exposée, et maintenez‑la à jour via inventaire, tests et amélioration continue.