CORS est stupide

1. Comprenez que CORS est une rustine destinée à compenser un défaut de conception des navigateurs.

• CORS (partage de ressources entre origines multiples) résout les problèmes de sécurité causés par les identifiants implicites dans les requêtes cross-origin.
• Le comportement par défaut des navigateurs expose les utilisateurs au risque d’attaques XSRF.
• CORS tente d’atténuer ces problèmes, mais présente des limites fondamentales en matière de sécurité.

2. CORS empêche la lecture du résultat des requêtes cross-origin, mais ne bloque pas la requête elle-même.

• fun-games.example ne peut pas lire les données de your-bank.example, mais peut tout de même exécuter des requêtes modifiant l’état, comme un virement de fonds.
• Cela vient de la manière dont les navigateurs gèrent par défaut les cookies et les identifiants.

3. Une sécurité cross-origin efficace commence par l’ignorance des identifiants implicites.

• Supprimez les cookies et identifiants similaires des requêtes cross-origin, ou autorisez-les explicitement.
• Utilisez les en-têtes Sec-Fetch-* pour filtrer les cookies cross-origin ou un middleware qui les supprime.

4. Les identifiants explicites sont une alternative plus sûre que les identifiants implicites.

• Utilisez l’en-tête Authorization pour les jetons d’authentification au lieu des cookies.
• Les identifiants explicites empêchent l’usage abusif des identifiants entre différents sites.
• Ce n’est pas adapté aux sites rendus côté serveur, mais c’est la meilleure approche pour les API et les applications côté client.

5. Implémentez les cookies SameSite afin de limiter l’utilisation d’identifiants cross-origin.

• Utilisez SameSite=Lax pour que, par défaut, les cookies ne soient pas inclus dans les requêtes cross-origin.
• Choisissez SameSite=Strict pour une politique plus stricte. Cela peut toutefois affecter l’utilisabilité (par ex. une déconnexion après une navigation cross-origin).

6. Adoptez une politique CORS simple et sûre.

• Politique par défaut : Access-Control-Allow-Origin: * et Access-Control-Allow-Methods: * n’autorisent qu’un accès anonyme.
• Cette politique désactive les identifiants implicites dans les requêtes cross-origin et protège le site contre un usage abusif involontaire des identifiants.

7. Ne rendez pas votre politique CORS inutilement complexe pour des raisons de sécurité.

• Des paramètres trop spécifiques peuvent créer un faux sentiment de sécurité.
• Les proxys CORS et autres contournements peuvent bypasser les politiques imposées par les navigateurs, ce qui annule les efforts de restriction d’accès.

8. Comprenez le mouvement plus large vers des valeurs par défaut plus sûres sur le Web.

• Les navigateurs explorent des approches comme State Partitioning (Firefox), Tracking Prevention (Safari) et CHIPS (Chrome) pour résoudre les problèmes d’identifiants cross-origin.
• Ces initiatives cherchent à améliorer la sécurité et la confidentialité des utilisateurs en limitant le partage des cookies et identifiants entre origines.

9. Reconnaissez que CORS est une solution incomplète.

• La rétrocompatibilité de CORS ajoute de la complexité sans résoudre complètement le problème de sécurité de base.
• Les navigateurs adoptent lentement de nouvelles approches pour atténuer ces problèmes, mais les progrès restent inégaux.