Les fonctionnalités de Facebook Login, telles que les tokens d’accès et les autorisations, permettent de protéger les utilisateur·ices et les applications, mais ces dernières doivent mettre en œuvre certaines mesures de sécurité de leur côté.
La liste de contrôle ci-dessous reprend les mesures de sécurité minimales que toute application utilisant Facebook Login doit mettre en œuvre. Votre application inclura également des fonctionnalités qui lui sont propres, vous devez donc constamment réfléchir à la meilleure façon de la sécuriser. Les utilisateur·ices d’une application non protégée risquent de ne plus avoir confiance en celle-ci et cesseront de l’utiliser.
La clé secrète est utilisée dans certains processus de connexion afin de générer des tokens d’accès. Elle permet également de restreindre l’accès à l’application aux seules personnes autorisées. La clé secrète permet de créer facilement un token d’accès d’application capable d’envoyer des requêtes d’API pour le compte de tout utilisateur ou toute utilisatrice de l’application. Par conséquent, il est essentiel que la clé secrète ne soit pas compromise.
C’est la raison pour laquelle il ne faut jamais inclure la clé secrète ou un token d’accès d’application à quelque code que ce soit.
Pour une sécurité optimale, nous vous conseillons d’utiliser uniquement les tokens d’accès d’application directement à partir des serveurs de votre application. Pour les applications natives, nous suggérons que l’application communique avec votre propre serveur, et que celui-ci envoie ensuite les requêtes d’API à Facebook à l’aide du token d’accès de l’application. Ainsi, si le type d’application indiqué sous Paramètres avancés dans l’Espace App est défini sur Native/Desktop
, nous partons du principe que votre application native contient la clé secrète ou un token d’accès d’application dans le fichier binaire, et nous n’autorisons aucun appel signé avec un token d’accès d’application. L’API se comportera comme si aucun token d’accès n’avait été fourni.
appsecret_proof
Vous pouvez demander à ce que les appels de serveur à serveur vers l’API de Facebook soient signés avec le paramètre appsecret_proof
afin de réduire l’exposition de votre application aux attaques de logiciels malveillants et de spammeurs. La preuve de clé secrète est un hachage sha256 de votre token d’accès qui utilise la clé secrète comme clé. La clé secrète est disponible dans le tableau de bord de votre application sous Paramètres > Paramètres de base.
L’exemple de code suivant illustre un appel en langage PHP :
$appsecret_proof= hash_hmac('sha256', $access_token.'|'.time(), $app_secret);
Certains systèmes d’exploitation et langages de programmation renvoient un horodatage correspondant à un nombre flottant. Veillez à convertir cette valeur en nombre entier avant de calculer la preuve de clé secrète. Certains langages de programmation créent le hachage sous la forme d’un objet condensé. Prenez soin d’exprimer le hachage en tant qu’objet hexadécimal.
Ajoutez le résultat sous forme de paramètre appsecret_proof
avec appsecret_time
défini sur l’horodatage utilisé lors du hachage de la clé secrète pour chaque appel effectué :
curl \ -F 'access_token=ACCESS-TOKEN' \ -F 'appsecret_proof=APP-SECRET-PROOF' \ -F 'appsecret_time=APP-SECRET-TIME' \ -F 'batch=[{"method":"GET", "relative_url":"me"},{"method":"GET", "relative_url":"me/accounts"}]' \ https://graph.facebook.com
Les preuves de clé secrète horodatées sont considérées comme expirées au bout de 5 minutes. Nous vous recommandons donc de générer une nouvelle preuve en ligne pour chaque appel de l’API Graph.
Pour activer l’option Demander la clé secrète pour tous vos appels d’API, accédez à l’Espace App Meta et cliquez sur Paramètres de l’application > Avancé dans le menu de gauche. Faites défiler jusqu’à la section Sécurité et activez l’option Demander la clé secrète.
Lorsque ce paramètre est activé, tous les appels initiés côté client doivent passer par votre backend. Celui-ci ajoutera le paramètre appsecret_proof
à la requête avant de la transmettre à l’API Graph, sans quoi l’appel échouera.
Dans certaines configurations, les applications réutilisent un token à long terme sur plusieurs serveurs clients. Ne procédez pas de la sorte. Utilisez plutôt des tokens à court terme générés avec le flux de code, comme expliqué dans notre documentation sur les tokens d’accès.
Pour mieux comprendre ce cas de figure, prenons l’exemple suivant : une app iOS native souhaite passer des appels d’API et, plutôt que de le faire directement, communique avec un serveur qui lui appartient pour lui transmettre un token généré à l’aide du SDK iOS. Le serveur utilise alors le token pour passer des appels d’API.
Le point de terminaison utilisé par le serveur pour recevoir le token peut être compromis, et d’autres personnes pourraient lui transmettre des tokens d’accès pour des applications totalement différentes. Il va de soi qu’il s’agit d’une faille de sécurité majeure, mais il existe un moyen de se protéger contre une telle éventualité : il ne faut jamais supposer que les tokens d’accès ont été générés par l’application qui les utilise. Ils doivent toujours faire l’objet d’une vérification à l’aide de points de terminaison de débogage.
Si vous n’utilisez pas les SDK Facebook, vérifiez régulièrement si le token d’accès est valide. Bien qu’ils aient une date d’expiration programmée, les tokens d’accès peuvent expirer plus tôt pour des raisons de sécurité. Si vous n’utilisez pas les SDK Facebook dans votre application, il est extrêmement important que vous mettiez en œuvre manuellement des contrôles fréquents de la validité des tokens (au moins quotidiennement) pour vous assurer que votre application ne dépend pas d’un token qui a expiré plus tôt pour des raisons de sécurité.
Si vous utilisez la boîte de dialogue Login de Facebook sur votre site Web, le paramètre state
est une chaîne unique qui protège votre application contre les attaques de type Falsification de requête intersite.
Le mode Strict protège vos applications en empêchant les personnes malveillantes de détourner votre redirection. L’activation du mode Strict est obligatoire pour toutes les applications.
Avant d’activer le mode Strict dans l’Espace App, vérifiez que votre trafic de redirection actuel fonctionne en effectuant les actions suivantes dans les paramètres Facebook Login :
Pour les applications avec des URI de redirection dynamique, utilisez le paramètre d’état pour renvoyer les informations dynamiques à un nombre limité d’URI de redirection. Ajoutez ensuite chacun des URI de redirection limité à la liste des URI de redirection OAuth valides.
Pour les applications avec un nombre limité d’URI de redirection, ajoutez chacun d’eux à la liste des URI de redirection OAuth valides.
Après avoir effectué ces actions, activez le mode Strict.
Le mode Strict empêche le détournement de vos URI de redirection en exigeant une correspondance exacte depuis votre liste des URI de redirection OAuth valides. Par exemple, si votre liste contient www.example.com, le mode Strict n’autorisera pas www.example.com/token comme redirection valide. Il n’autorisera pas non plus tout paramètre de requête supplémentaire ne figurant pas dans votre liste des URI de redirection OAuth valides.
Utilisez le protocole Internet HTTPS plutôt que le protocole HTTP, car il utilise le chiffrement. Le protocole HTTPS assure donc la confidentialité des données transmises et les protège contre les attaques malveillantes. Il empêche également que les données soient modifiées pendant la transmission par l’insertion, par exemple, de publicités ou d’un code malveillant.
À partir du 6 octobre 2018, toutes les applications devront utiliser le protocole HTTPS.
Lorsque vous indiquez que vous utilisez le SDK JavaScript pour vous connecter en configurant l’option de connexion avec le SDK JavaScript sur « oui », le domaine de votre page qui héberge le SDK doit correspondre à l’une des entrées de la liste Domaines autorisés pour le SDK Javascript. Cela garantit que les tokens d’accès sont uniquement renvoyés aux rappels dans les domaines autorisés. Seules les pages HTTPS sont prises en charge pour les actions d’authentification avec le SDK JavaScript de Facebook.
Pour les intégrations JSSDK existantes créées avant le 10 août 2021, cette liste est remplie avec des valeurs basées sur l’utilisation actuelle. Aucune autre action n’est requise.
Pour les nouvelles intégrations créées après le 10 août 2021, vous devez ajouter des valeurs à cette liste.
Si vous voyez que le champ du domaine JSSDK de votre application contient des URL qui commencent par *.
, veuillez modifier ce contenu de façon à le remplacer par des URL absolues pour plus de sécurité.
Les attaques de redirection ouvertes surviennent lorsqu’une personne malveillante fournit un paramètre redirect_uri non autorisé lors de la demande de connexion, entraînant la fuite éventuelle d’informations sensibles telles qu’un token d’accès vers la chaîne ou le fragment de requête dans l’URI de redirection.
Pour les intégrations Web personnalisées, vous devez fournir des URI de redirection autorisés dans les paramètres de votre application pour empêcher de telles attaques. Pour répondre à une demande de connexion, le paramètre redirect_uri sera comparé aux entrées de cette liste. L’URI complet doit être identique, y compris tous les paramètres, à l’exception du paramètre d’état facultatif, dont la valeur est ignorée.
Le SDK JavaScript repose généralement sur des pop-ups et des rappels pour effectuer une connexion. Pour certains navigateurs dans l’application qui suppriment les pop-ups, cela peut échouer. Si tel est le cas, le SDK tentera automatiquement de procéder à une redirection, avec un token d’accès, vers la page qui l’a invoqué. Il peut uniquement procéder à une redirection en toute sécurité si l’URI complet de la page est répertorié dans la liste des URI de redirection OAuth valides.
Si les scénarios de navigateur dans l’application sont importants pour votre application Web, vous devez ajouter le domaine de votre page de connexion aux domaines autorisés, ainsi que son URI complet (y compris le chemin et les paramètres de requête), aux URI de redirection OAuth valides. Si les URI varient beaucoup lors de la connexion à votre application, vous pouvez spécifier manuellement une option fallback_redirect_uri dans l’appel FB.login(), de sorte que vous aurez simplement besoin d’ajouter cette entrée à votre liste d’URI de redirection OAuth valides.
Activez et/ou désactivez tout processus d’authentification non utilisé par l’application pour réduire l’exposition à des attaques.
Utilisez des tokens d’accès à court terme générés par un code dans les clients plutôt que des tokens générés par les clients ou des tokens à long terme fournis par un serveur. Le processus associé aux tokens d’accès à court terme générés par un code requiert que l’application échange le code contre un token, et ce processus est plus sûr que l’obtention d’un token dans le navigateur. Les applications doivent privilégier ce processus autant que possible pour une sécurité optimale. La seule activation de ce processus par une application permet d’empêcher un logiciel malveillant présent sur l’ordinateur d’un·e utilisateur·ice d’obtenir un token d’accès et de l’utiliser à des fins malhonnêtes. Pour en savoir plus, consultez notre documentation sur les tokens d’accès.
Désactivez le processus de connexion OAuth côté client si votre application ne l’utilise pas. Le processus de connexion OAuth côté client est un bouton permettant d’activer ou de désactiver l’utilisation des flux de tokens client OAuth. Si votre application n’utilise aucun processus OAuth côté client, ce qui est le cas des SDK associés au Facebook Login, vous devez désactiver ce processus. Notez, cependant, que vous ne pouvez pas demander d’autorisations pour un token d’accès si votre processus de connexion OAuth côté client est désactivé. Ce paramètre se trouve dans la section Produits > Facebook Login > Paramètres de l’Espace App.
Désactivez le processus OAuth sur le Web ou spécifiez une liste de redirections autorisées. Les paramètres de la connexion OAuth sur le Web permettent à tout processus OAuth associé à un token client et utilisant la boîte de dialogue Login sur le Web de Facebook de renvoyer des tokens vers votre propre site Web. Ce paramètre se trouve dans la section Produits > Facebook Login > Paramètres de l’Espace App. Désactivez ce paramètre si vous ne créez pas de processus de connexion sur le Web personnalisé ni n’utilisez le SDK Facebook Login sur le Web.
Appliquez le protocole HTTPS. Ce paramètre doit utiliser HTTPS pour toutes les redirections OAuth et exige que tous les appels SDK Facebook pour Javascript de renvoyant ou exigeant un token d’accès se fassent uniquement depuis des pages HTTPS. Toutes les nouvelles applications créées à partir de mars 2018 ont ce paramètre activé par défaut. Nous vous conseillons de prévoir une migration des applications existantes pour n’utiliser que des URL HTTPS d’ici le 6 octobre 2018. La plupart des grands hébergeurs d’applications sur le cloud proposent une configuration automatique et gratuite des certificats TLS pour vos applications. Si vous hébergez vous-même votre application ou que votre service d’hébergement n’offre pas le protocole HTTPS par défaut, vous pouvez obtenir un certificat gratuit pour vos domaines sur Let’s Encrypt.
Désactivez le processus OAuth intégré dans un navigateur si votre application ne l’utilise pas. Certaines applications natives sur ordinateur ou mobile authentifient les utilisateur·ices par l’intermédiaire du processus OAuth côté client au sein d’une webview intégrée. Si votre application n’utilise pas cette méthode d’authentification, désactivez-la dans la section Produits > Facebook Login > Paramètres de l’Espace App.
Désactivez les processus d’authentification unique pour mobile si votre application ne les utilise pas. Si votre application n’utilise pas la Connexion iOS ou Android, désactivez le paramètre Authentification unique dans les sections Paramètres > Paramètres de base sur iOS et Android.
L’Espace App contient plusieurs paramètres supplémentaires qui permettent aux développeurs de contrer les attaques qui pourraient nuire à la sécurité :
Native/Desktop
pour éviter tout risque de décompilation de votre application ou de vol de votre clé secrète.