Comment sécuriseriez-vous une API REST exposée publiquement ?

Sécuriser une API consiste à contrôler qui peut l'appeler, ce qu'ils peuvent faire et ce qu'ils peuvent envoyer — à chaque requête, car une API est sans état et chaque requête doit tenir par elle-même.

Authentification vs autorisation

Elles sont distinctes et toutes deux requises. L'authentification prouve qui est l'appelant — généralement un jeton bearer à courte durée de vie issu d'OAuth2/OIDC, validé à chaque requête (signature, expiration, audience). L'autorisation décide de ce que cet appelant authentifié peut faire. La faille d'API la plus courante et la plus dommageable est l'autorisation au niveau objet défaillante (BOLA/IDOR) : le code authentifie l'utilisateur mais renvoie ensuite l'objet /orders/123 sans vérifier que la commande 123 lui appartient réellement. Vérifiez toujours la propriété de la ressource spécifique, pas seulement que quelqu'un est connecté.

Transport et entrées

• TLS partout — n'acceptez jamais le clair, et ne mettez pas de secrets ou de jetons dans les query strings où ils atterrissent dans les journaux.
• Validez et contraignez les entrées côté serveur selon un schéma strict ; rejetez les champs inattendus et les charges utiles surdimensionnées. Ne faites jamais confiance à la validation côté client.
• Paramétrez les requêtes et encodez la sortie pour bloquer les injections.

Abus et visibilité

• La limitation de débit et les quotas protègent contre le brute force, le scraping et le déni de service ; ajustez-les différemment pour les appelants authentifiés vs anonymes.
• La journalisation et la surveillance des échecs d'authentification et des schémas d'accès anormaux permettent de détecter les attaques en cours.
• Minimisez l'exposition des données — ne renvoyez que les champs dont le client a besoin, afin que l'API ne divulgue pas de données internes via des réponses trop larges.

Ce que les recruteurs recherchent

Les candidats qui disent seulement « utiliser des clés d'API » passent à côté de l'essentiel. La bonne réponse sépare l'authentification de l'autorisation, désigne les contrôles d'accès au niveau objet (BOLA/IDOR) comme le principal risque concret, et complète le tout par TLS, la validation des entrées et la limitation de débit.