API exposees : les portes cachees de votre site web

Votre site web a une porte d'entree que les visiteurs voient : les pages, les formulaires, la navigation. Mais derriere cette porte d'entree, il y a des dizaines d'autres portes que la plupart des gens ne remarquent jamais. Ce sont vos API, interfaces de programmation applicative, et elles sont la maniere dont les composants de votre site communiquent entre eux et avec les services externes.

Le probleme est que beaucoup de ces portes sont deverrouillees. Certaines sont grandes ouvertes. Et les attaquants savent exactement comment les trouver.

Cet article explique ce que sont les API dans le contexte d'un site professionnel, pourquoi elles constituent un probleme de securite, comment les attaquants les decouvrent et les exploitent, et ce que vous pouvez faire pour vous proteger.

Que sont les API et pourquoi chaque site moderne en possede

Une API est un moyen pour les composants logiciels de communiquer. Quand vous remplissez un formulaire de contact sur un site web, les donnees sont envoyees a un endpoint API sur le serveur. Quand une page charge des listes de produits, elle peut recuperer ces donnees depuis une API. Quand votre site s'integre avec un processeur de paiement, un service email ou un CRM, ces integrations se font via des API.

Meme un simple site professionnel a typiquement des API pour :

• Soumission de formulaire de contact - donnees envoyees du navigateur au serveur.
• Fonctionnalite de recherche - requetes envoyees a un endpoint de recherche qui retourne des resultats.
• Authentification utilisateur - connexion, deconnexion, endpoints de reinitialisation de mot de passe.
• Gestion de contenu - le CMS utilise des API pour creer, lire, mettre a jour et supprimer du contenu.
• Integrations tierces - analytics, processeurs de paiement, marketing par email, widgets de chat.

WordPress REST API : exposition des donnees utilisateur par defaut

WordPress est livre avec une REST API complete activee par defaut depuis la version 4.7. Cette API expose des donnees dont la plupart des proprietaires de sites ne realisent pas qu'elles sont publiques.

Ce que la WordPress REST API expose

Essayez ceci sur n'importe quel site WordPress : naviguez vers /wp-json/wp/v2/users. Sur de nombreux sites, vous verrez une reponse JSON listant tous les comptes utilisateurs, y compris les noms d'utilisateur, les noms d'affichage, les ID utilisateurs et les URL de profil. Ces informations sont disponibles pour tout le monde sans authentification.

Pourquoi c'est important

L'enumeration des noms d'utilisateur est le point de depart des attaques par force brute. Si un attaquant connait les noms d'utilisateur de votre site WordPress (et la REST API vient de les lui fournir), il peut commencer a essayer de deviner les mots de passe. Combine avec l'endpoint /wp-login.php et l'absence de rate limiting ou de verrouillage de compte, c'est un chemin d'attaque direct.

Nous avons discute de risques associes dans notre article sur les pages d'administration exposees.

Introspection GraphQL laissee activee

GraphQL est une alternative aux API REST qui devient de plus en plus courante. Il permet aux clients de demander exactement les donnees dont ils ont besoin en une seule requete.

Le probleme de l'introspection

GraphQL a une fonctionnalite integree appelee introspection qui permet a quiconque d'interroger le schema complet de l'API. Cela signifie qu'un attaquant peut decouvrir chaque type, chaque champ, chaque relation et chaque mutation disponible dans votre API, simplement en envoyant une seule requete :

{ __schema { types { name fields { name type { name } } } } }

C'est comme remettre a un attaquant un plan complet de la structure de votre base de donnees et de chaque operation que votre API supporte.

La solution

Desactivez l'introspection en production. Chaque bibliotheque GraphQL majeure fournit une option de configuration pour cela. Dans Apollo Server : introspection: false. Cela devrait faire partie de votre checklist de deploiement.

Endpoints API non authentifies

Au-dela de WordPress et GraphQL, de nombreux sites web et applications personnalises ont des endpoints API qui manquent d'authentification appropriee. Cela arrive pour plusieurs raisons courantes :

• Raccourcis de developpement : L'authentification "devait etre ajoutee plus tard" et ne l'a jamais ete.
• Obscurite presumee : Le developpeur a suppose que personne ne trouverait l'endpoint car il n'est lie depuis aucune page. C'est de la securite par l'obscurite, et ca ne fonctionne pas.
• Middleware mal configure : Le middleware d'authentification a ete applique a la plupart des routes mais en a manque certaines.
• Endpoints legacy : D'anciens endpoints API d'une version precedente de l'application jamais correctement decommissionnes.

Vulnerabilites IDOR : quand l'authentification ne suffit pas

IDOR signifie Insecure Direct Object Reference. Cela se produit quand une API utilise un identifiant previsible (comme un numero sequentiel) pour referencer des objets, et ne verifie pas que l'utilisateur demandeur a la permission d'acceder a cet objet specifique.

Comment fonctionne IDOR

Imaginez un endpoint API comme /api/factures/1234 qui retourne les details d'une facture. Vous etes connecte et demandez votre propre facture. Maintenant changez le numero en 1235. Si l'API retourne la facture de quelqu'un d'autre, c'est une vulnerabilite IDOR.

L'API a verifie que vous etes authentifie (vous etes connecte), mais elle n'a pas verifie l'autorisation (si vous avez la permission d'acceder a la facture 1235). C'est l'un des types de vulnerabilites les plus courants dans les applications web et figure regulierement dans le OWASP Top 10.

Rate limiting : la protection manquante

Le rate limiting restreint le nombre de requetes qu'un client peut faire a une API dans un laps de temps donne. Sans cela, les attaquants peuvent :

• Forcer les endpoints de connexion : Essayer des milliers de combinaisons de mots de passe par minute.
• Enumerer les donnees : Telecharger votre base de donnees entiere en faisant des milliers de requetes API sequentielles.
• Deni de service : Submerger votre serveur de requetes, le rendant indisponible pour les utilisateurs legitimes.

Type d'endpoint	Limite suggeree	Justification
Connexion / Authentification	5-10 tentatives par minute par IP	Empeche les attaques par force brute
Reinitialisation de mot de passe	3 requetes par heure par email	Empeche le bombardement d'emails
Formulaire de contact	5 soumissions par heure par IP	Empeche le spam
Recherche	30 requetes par minute par IP	Empeche le scraping de donnees
API generale	100 requetes par minute par utilisateur	Empeche les abus tout en permettant l'utilisation normale

Cles API dans le JavaScript frontend

C'est l'une des erreurs les plus courantes que nous trouvons lors des audits de sites web. Les developpeurs integrent des cles API, des tokens secrets et des identifiants directement dans le code JavaScript cote client. Puisque tout le JavaScript servi au navigateur est visible par quiconque ouvre les outils de developpement, ces secrets sont effectivement publics.

Ce que nous trouvons dans le code source JavaScript

• Cles API Google Maps (souvent avec la facturation activee et aucune restriction).
• Configuration Firebase incluant les URL de base de donnees et les cles API.
• Cles API de processeurs de paiement (parfois incluant les cles secretes).
• Tokens API du CMS avec des permissions d'ecriture.
• Cles API de services d'email (SendGrid, Mailgun, etc.).

Comment corriger

1. Ne mettez jamais de cles secretes dans le code frontend. Seules les cles publiques/publiables devraient etre dans le JavaScript cote client.
2. Utilisez des variables d'environnement sur le serveur. Gardez les secrets dans les variables d'environnement cote serveur.
3. Restreignez les cles API par domaine. Google Cloud, AWS et la plupart des services permettent de restreindre les cles API a des domaines ou adresses IP specifiques.
4. Faites passer les appels API sensibles par votre backend. Au lieu d'appeler une API tierce directement depuis le navigateur, routez la requete via votre serveur.
5. Effectuez la rotation des cles exposees immediatement. Si vous decouvrez qu'une cle a ete exposee, generez une nouvelle cle et revoquez l'ancienne.

Comment les attaquants enumerent et exploitent les API

Phase de decouverte

• Outils de developpement du navigateur : Ouvrez l'onglet Network et naviguez sur le site. Chaque appel API est visible.
• Analyse du code source JavaScript : Lisez les fichiers JavaScript du site. Les endpoints API, les cles et parfois les tokens d'authentification sont integres dans le code.
• Scan de chemins courants : Des outils comme DirBuster ou ffuf testent des chemins API courants : /api/, /v1/, /graphql, /wp-json/.
• Source maps JavaScript : Si les source maps sont deployees en production, elles revelent la structure du code source original.

Outils utilises par les attaquants

• Postman : A l'origine un outil legitime de developpement API, couramment utilise pour creer et rejouer des requetes API avec des parametres modifies.
• Burp Suite : Un outil professionnel de test de securite web. La fonction proxy intercepte et modifie chaque requete entre le navigateur et le serveur.
• cURL : Le client HTTP en ligne de commande. Simple, puissant et disponible sur chaque systeme.
• OWASP ZAP : Une alternative open-source a Burp Suite avec des capacites similaires.

Comment securiser vos API

Authentification

Chaque endpoint API qui n'est pas explicitement public devrait exiger une authentification. Utilisez des mecanismes standards : JWT, OAuth 2.0, cles API pour la communication entre services, cookies de session pour les applications navigateur.

Autorisation

L'authentification confirme l'identite. L'autorisation confirme la permission. Les deux sont necessaires. Implementez un controle d'acces base sur les roles ou les attributs. Verifiez l'autorisation a chaque requete, pour chaque ressource.

Validation des entrees

Validez chaque entree cote serveur. Ne faites jamais confiance aux donnees venant du client. Verifiez les types de donnees, les limites de longueur, la validation de format, les valeurs autorisees et l'encodage.

CORS

Cross-Origin Resource Sharing (CORS) controle quels domaines peuvent faire des requetes a votre API depuis un navigateur. Une politique CORS mal configuree (comme autoriser toutes les origines avec Access-Control-Allow-Origin: *) peut permettre aux attaquants de faire des appels API depuis leurs propres sites web en utilisant les sessions authentifiees de vos utilisateurs.

Checklist pratique d'audit

1. Ouvrez votre site dans un navigateur avec les outils de developpement ouverts. Allez a l'onglet Network. Naviguez sur chaque page et cliquez sur chaque bouton. Combien d'appels API voyez-vous ?
2. Pour chaque endpoint, essayez d'y acceder sans authentification. Quelles donnees retourne-t-il ?
3. Verifiez la WordPress REST API : visitez /wp-json/wp/v2/users. Pouvez-vous voir les noms d'utilisateur ?
4. Verifiez GraphQL : essayez /graphql avec une requete d'introspection. Repond-il ?
5. Regardez les fichiers source JavaScript. Y a-t-il des cles API ou des identifiants integres ?
6. Essayez de modifier les ID numeriques dans les requetes API. Pouvez-vous acceder aux donnees d'autres utilisateurs ?
7. Envoyez 100 requetes a un endpoint sensible en succession rapide. Etes-vous limite ?

Prochaines etapes

La securite des API est un domaine specialise qui necessite a la fois des connaissances techniques et une comprehension de votre application specifique. Chez Envestis, nous realisons des evaluations approfondies de la securite des API pour les entreprises a Lugano et dans toute la Suisse.

Si vous n'etes pas sur de la securite des API de votre site web, contactez-nous pour une evaluation de securite. Nous cartographierons la surface de vos API, testerons les vulnerabilites decrites dans cet article et vous donnerons un rapport clair de ce qui doit etre corrige et comment.