CORS ne protège pas votre API. Il protège vos utilisateurs.

CORS est un mécanisme de sécurité qui régule les échanges entre origines différentes dans un navigateur, protégeant les utilisateurs contre la lecture non autorisée de données sensibles par des scripts malveillants. Il ne protège pas directement le serveur contre des requêtes non désirées, mais contrôle l'accès aux réponses pour les scripts JavaScript. Une mauvaise configuration peut cependant introduire des vulnérabilités, notamment en combinant des headers permissifs avec des credentials.

• Rôle de CORS : Limite la lecture des réponses cross-origin par des scripts tiers, sans empêcher l'exécution des requêtes côté serveur. Par exemple, un site malveillant ne peut pas lire le solde bancaire d'un utilisateur connecté à sa banque via une requête JavaScript.
• Types de requêtes :
  • Simple requests (GET/POST avec Content-Type standard) : le navigateur envoie la requête avant de vérifier les headers CORS, mais bloque la lecture de la réponse si non autorisée.
  • Requêtes avec preflight : un OPTIONS préalable vérifie les permissions avant l'envoi de la requête principale.
• Bonnes pratiques :
  • Éviter Access-Control-Allow-Origin: * avec Access-Control-Allow-Credentials: true pour prévenir les fuites de données.
  • Concevoir l'API comme si CORS n'existait pas : valider systématiquement l'authentification et les permissions sur chaque endpoint, indépendamment de l'origine de la requête.
• Limites et confusions : CORS ne remplace pas une authentification robuste (JWT, sessions, clés API). Une API accessible via curl sans restrictions relève d'un choix d'architecture, pas d'un problème de CORS.