Sécurité des API de votre site : authentification, limitation de débit, CORS, validation des entrées et protection contre les failles
1. Pourquoi « avoir activé HTTPS » ne signifie pas que votre API est sécurisée
Beaucoup de webmasters assimilent HTTPS à la sécurité : puisque le trafic entre le navigateur et le serveur est chiffré, l’API serait fiable. C’est la première erreur de raisonnement : HTTPS résout le problème de « l’écoute clandestine en chemin », mais pas celui d’« une identité légitime détournée pour spammer », ni celui d’« un script malveillant qui martèle votre endpoint de connexion », ni celui d’« une requête contenant du SQL qui exfiltre une table ».
Le jugement contre-intuitif est ici :Ce qui fait réellement tomber un site, ce sont presque toujours des failles applicatives, pas des failles de transport. Exfiltration de base, suppression de base, endpoints saturés : dans 90 % des cas, la cause est une entrée non validée, une authentification mal implémentée ou une limitation de débit absente. Un WAF peut bloquer certaines signatures d’attaque connues, mais pas les failles issues de votre propre logique métier. C’est ce que confirment les conclusions de Après un piratage de site: nettoyez d’abord le code, on parlera de durcissement ensuite.
Chaque couche de défense couvre un périmètre précis ; s’il en manque une, une catégorie d’attaque passe directement. Le tableau ci-dessous récapitule pour chaque couche « ce qu’elle bloque » et « ce qui se passe si elle manque ».
| Couche de défense | Attaques bloquées | Implémentation typique | Conséquence si oublié |
|---|---|---|---|
| Certifications | Appels anonymes, usurpation d’identité | API Key, JWT, OAuth2 | Endpoints de données accessibles à n’importe qui |
| Limitation de débit | Énumération par force brute, spam massif des endpoints | Fenêtre glissante par IP/clé | Credential stuffing sur l’endpoint de connexion, exfiltration de la base |
| CORS | Lecture cross-origin des données par un site malveillant | Liste blanche d’origines | Données lues par un site tiers alors que l’utilisateur est connecté |
| Validation des entrées | Injection SQL, XSS, écriture de données corrompues | Validation par liste blanche + requêtes paramétrées | Base entière exfiltrée, back-office compromis par XSS et détournement de session |
| Analyse des failles | Portes dérobées connues, dépendances obsolètes | Analyse des dépendances + scan régulier des failles | Utilisation d’un ancien plugin avec un exploit public |
2. Authentification : comment choisir entre les trois méthodes et gérer les clés
Les API exposées d’un site se divisent en deux catégories : celles destinées au navigateur front-end (session de connexion, soumission de formulaire) et celles destinées à l’intégration avec des systèmes externes (Webhook, synchronisation tierce). Les méthodes d’authentification diffèrent selon la catégorie : ne les mélangez pas.
Côté front, utilisez un JWT pour la session : le jeton a une date d’expiration, 2 heures par défaut, et se renouvelle via un refresh token. Pour les systèmes externes, passez une API Key de longue durée dans l’en-tête de la requête, jamais dans les paramètres d’URL : les URL finissent dans les logs et l’historique du navigateur. Ne recourez à OAuth2 que lorsqu’il faut “laisser un utilisateur autoriser un tiers à accéder en son nom”. Dans 90 % des cas d’un site indépendant, c’est inutile et vous vous ajoutez de la complexité pour rien.
Le critère : si l’interface ne sert qu’à votre propre front, un JWT suffit. Si un partenaire doit l’appeler depuis son programme, émettez une API Key dédiée, une par partenaire, pour pouvoir la révoquer individuellement à tout moment. Renouvelez les clés une fois par trimestre, en laissant l’ancienne et la nouvelle coexister 7 jours pour éviter de couper le partenaire d’un coup.
| Méthode d’authentification | Cas d’usage | Durée de validité du jeton | Rotation / révocation |
|---|---|---|---|
| Cookie de session | Back-office à connexion par formulaire classique | Session navigateur | Invalide à la déconnexion |
| JWT | Front et back séparés, front qui appelle l’API | Jeton d’accès 2 heures | refresh 7 jours, liste noire côté serveur |
| Clé API | Systèmes externes, callbacks Webhook | Longue durée, une par partenaire | Rotation trimestrielle, révocation individuelle |
| OAuth2 | Une app tierce agit au nom de l’utilisateur | access + refresh de courte durée | L’utilisateur peut révoquer à tout moment |
3. Limitation de débit : qui limiter, quel seuil
L’erreur la plus fréquente en limitation de débit, c’est un seuil unique pour tout le site. La fréquence normale d’appel d’une interface de connexion et celle d’une liste de produits diffèrent d’un ordre de grandeur : avec un seuil unique, soit vous pénalisez de vrais utilisateurs, soit vous ne bloquez pas l’attaque. La bonne approche : des paliers par interface et une limitation par dimension.
Trois dimensions se cumulent : par IP pour empêcher un attaquant de saturer, par compte pour bloquer un dictionnaire de mots de passe qui teste en boucle, par API Key pour contenir un programme partenaire qui s’emballe. Les seuils doivent être chiffrés ; le tableau ci-dessous donne les valeurs de départ des interfaces courantes d’un site indépendant, à recalibrer après la mise en ligne selon le trafic réel.
Exemple concret : L’interface de connexion se fait attaquer par bourrage d’identifiants. Configurez 10 tentatives par minute et par IP, 5 échecs par minute et par compte, et un bannissement automatique de l’IP pendant 1 heure après 5 minutes de dépassement. C’est plus efficace qu’un simple “verrouillage du compte après 5 échecs”, car l’attaquant teste le même mot de passe sur différents comptes : un seuil par compte ne suffit pas. Pour traiter le trafic indésirable lié aux formulaires, voyez Fiabilité du formulaire de demande de devis les méthodes anti-spam.
| Type d’interface | Dimension de limitation | Seuil de départ | Action en cas de dépassement |
|---|---|---|---|
| Connexion / mot de passe oublié | IP + compte | 10 fois/minute | Bannissement temporaire 1 heure |
| Envoi du formulaire de contact | IP | 3 fois/minute | Affichage d’un captcha |
| Liste de produits publique | IP | 60 fois/minute | Réponse 429 |
| Intégration API externe | Clé API | QPS prévu au contrat | 429 + notification au partenaire |
| Recherche sur le site | Session | 20 fois/minute | Réponse 429 |
4. CORS : quand l’activer, et jusqu’où
CORS (Cross-Origin Resource Sharing) est une protection intégrée au navigateur : par défaut, le script de votre page ne peut pas lire la réponse d’une API tierce depuis un autre domaine. Ce n’est pas « l’activer qui rend vulnérable », c’est « mal le configurer qui rend vulnérable ». L’erreur la plus fréquente, par facilité, consiste à écrire Access-Control-Allow-Origin: * puis à ajouter Allow-Credentials: true : c’est ouvrir grand la porte des requêtes cross-origin à tout Internet.
Règle de décision : si votre API n’est appelée que par votre propre front-end, la liste blanche CORS ne doit contenir que votre propre domaine (avec et sans www), jamais *. Si un front-end tiers doit l’appeler, ajoutez les domaines un par un, sans motif flou du type *.votredomaine.com : dès qu’un sous-domaine est enregistré ou compromis, il devient une surface d’attaque.
Une API purement publique sans cookie (une liste de produits, par exemple) n’a en réalité pas besoin d’activer les identifiants CORS : le navigateur est moins strict sur les requêtes simples, et une option en moins, c’est une surface de risque en moins. Pour la frontière entre identifiants et conformité des données transfrontalières, voir Fondations de conformité pour un site à l’international les explications sur les cookies et les transferts de données transfrontaliers.
| Situation | Configuration Allow-Origin | Allow-Credentials | Sécurisé ? |
|---|---|---|---|
| Appelée uniquement par son propre front-end | Liste blanche limitée à son propre domaine | true (session requise) | Sécurité |
| API publique de données produits | Non configuré ou * | false | Sécurité |
| * par facilité + identifiants true | * | true | Dangereux, à corriger impérativement |
| Regex *.votredomaine.com | Correspondance floue | true | Dangereux, un sous-domaine compromis suffit |
| Plusieurs front-ends partenaires | Liste blanche domaine par domaine | true | Sécurisé, nettoyer régulièrement les entrées inutiles |
V. Validation des entrées et protection contre les vulnérabilités : bloquer les données sales à la porte
La validation des entrées est, sur les cinq couches, celle qu’une équipe d’une seule personne oublie le plus souvent et dont les conséquences sont les plus lourdes. Un seul principe :ne jamais faire confiance aux données venant du front-end ou d’API externes. Validez chaque paramètre d’entrée par liste blanche : type, longueur, format, valeurs d’énumération. En cas de non-conformité, refusez directement, sans tenter de « nettoyer puis réutiliser ».
L’injection SQL se règle définitivement par des requêtes paramétrées, jamais par concaténation de chaînes SQL. Le XSS se règle définitivement par l’échappement en sortie : on n’échappe pas le contenu utilisateur au moment de l’enregistrer en base, on l’échappe à l’affichage selon le contexte (les règles d’échappement diffèrent en contexte HTML, JS et URL). Pour l’upload de fichiers, limitez la liste blanche des extensions, renommez les fichiers et stockez-les hors du répertoire web. Ce sont les bases de l’OWASP Top 10, sans aucune « astuce avancée ».
Intégrez l’analyse des vulnérabilités à un rythme fixe : scan automatique hebdomadaire du fichier de verrouillage des dépendances ; en cas de faille critique (score CVE supérieur à 9), mise à jour ou désactivation temporaire de la fonctionnalité sous 72 heures ; scan passif mensuel de tout le site, avec nettoyage des extensions obsolètes d’après les résultats. Pour le branchement des alertes de surveillance, voir Surveillance et alertes du site. Pour les compromis de sécurité propres à votre stack technique, comparez avec Stack technique crater.
| Protection | Mise en œuvre | Fréquence / Seuil | Ligne rouge |
|---|---|---|---|
| Validation des paramètres d’entrée | Type + longueur + énumération en liste blanche | Obligatoire pour chaque API | Interdit de valider uniquement côté front-end |
| Injection SQL | Requêtes paramétrées / requêtes préparées | À vérifier en revue de code | Interdire la concaténation SQL |
| XSS | Échapper les sorties selon le contexte | Tous les points de sortie utilisateur | Interdire la sortie brute de texte riche non nettoyé |
| Upload de fichiers | Liste blanche d’extensions + renommage | Obligatoire sur toute interface d’upload | Interdire l’exécution de scripts dans le dossier d’upload |
| Scan des dépendances vulnérables | Scan automatique du fichier de verrouillage | Une fois par semaine | Corriger sous 72 heures les failles critiques notées 9 et plus |
FAQ — Questions fréquentes
Faut-il forcément un WAF pour qu’un site indépendant soit sécurisé ?
JWT ou API Key : lequel choisir ?
Comment fixer les seuils de limitation sans pénaliser les utilisateurs normaux ?
Quel problème pose Access-Control-Allow-Origin: * en CORS ?
Pourquoi valider les entrées côté serveur si c’est déjà fait côté front ?
À quelle fréquence faut-il scanner les vulnérabilités ?
Pour conclure
La sécurité des API d’un site indépendant ne tient pas à l’empilement d’outils, mais à une défense en couches : si une couche est contournée, la suivante peut encore bloquer. Une défense sur un seul point est la plus fragile : vous avez beau configurer un WAF impeccable, sans validation des entrées, l’injection atteint quand même la base de données. Sur les cinq couches, commencez par la validation des entrées et l’authentification : ce sont les deux plus rentables pour un effort minimal. La limitation de débit et le CORS relèvent de la configuration, réglables en une demi-journée, et le scan de vulnérabilités devient une tâche automatique hebdomadaire.
Trois étapes pour passer à l’action : d’abord, ajouter une authentification à toutes les interfaces externes, avec des clés longue durée distinctes par partenaire ; ensuite, appliquer une limitation de débit graduée aux interfaces de connexion et de formulaire, en restant permissif sur les interfaces publiques ; enfin, valider chaque paramètre d’entrée côté backend avec une liste blanche, et intégrer l’analyse des dépendances aux tâches hebdomadaires. Une fois ces trois étapes faites, vos interfaces seront « occasionnellement sondées » plutôt que « grandes ouvertes ». Pour le rythme de maintenance au quotidien, reportez-vous à calendrier de maintenance du site et planifiez le tout ensemble.
Une phrase à retenir : la sécurité des API n’est pas un mur, c’est cinq portes — chacune doit être verrouillée, il suffit d’en oublier une pour que les quatre autres ne servent à rien.