API (Activer les paramètres OAuth) : Contrôle des paramètres du flux Code d'autorisation et identifiants

Nom du contrôle

Applications connectées : API (Activer les paramètres OAuth) : Paramètres du flux Code d'autorisation et identifiants

Configuration recommandée

Activez le flux Code d'autorisation et identifiants.

Ne pas demander ou désélectionnez Demander un secret pour le flux serveur Web et Demander un secret pour le flux de jeton d'actualisation.

Vue d'ensemble du contrôle

Ce contrôle configure les exigences de sécurité spécifiques pour le « flux Code d'autorisation et identifiants », en déterminant si un Secret client doit être validé selon que l'application est un « Client privé » (côté serveur) ou un « Client public » (navigateur/mobile).

Risque de sécurité s'il n'est pas configuré

Le fait d'exiger un secret incorrect pour des clients publics force le codage dur des identifiants dans un code frontal où ils sont facilement volés, alors que le fait de ne pas exiger un secret pour des clients privés permet aux assaillants d'échanger des codes interceptés sans avoir besoin de la clé privée de l'application.

Scénarios de menace

Un assaillant décompile une application mobile pour extraire un Secret client codé en dur ou intercepte un code d'autorisation d'une application côté serveur et l'échange avec succès contre un jeton d'accès à privilège élevé, car aucun secret n'était requis pour l'échange.

Plage de score CVSS estimée

Critique (9,0 à 10,0).

Considérations relatives à l'impact sur le risque

Une mauvaise configuration entraîne la compromission des identifiants clients ou l'activation du piratage de session non autorisé, les deux entraînant un accès permanent et non authentifié à des données confidentielles.

Risque plus élevé quand

Lorsque le flux est utilisé pour des intégrations à privilèges élevés qui n'ont pas de PKCE (clé de vérification pour l'échange de code) comme défense secondaire ou lorsque des secrets sont stockés dans des référentiels côté client en texte brut.

Risque faible quand

Lorsque les « Clients privés » appliquent strictement les secrets stockés dans des coffres-forts côté serveur sécurisés et que les « Clients publics » utilisent PKCE pour sécuriser l'échange sans avoir besoin d'un secret partagé vulnérable.

Considérations relatives à l'entreprise et à l'intégration

L'implémentation correcte nécessite une distinction architecturale claire entre les applications pilotées par le back-end et les applications pilotées par le front-end afin de s'assurer que la stratégie « Secret » appropriée est appliquée sans rompre la poignée de main d'authentification.

Remédiation recommandée

Pour des clients privés/côté serveur, sélectionnez « Nécessite un secret pour le flux serveur Web » et « Nécessite un secret pour le flux de jeton d'actualisation ». Pour des clients publics/mobiles, désélectionnez ces options et implémentez à la place PKCE.

Guide d'examen sanitaire de sécurité

Security Health Review souligne que la sécurité d'un secret dépend entièrement de la capacité du client à le protéger, et exige qu'aucun secret partagé ne soit jamais exposé au navigateur ou à l'environnement mobile.