> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Décrit différents types de cyberattaques et les mesures qui peuvent être prises pour les prévenir.

# Prévenir les menaces de cybersécurité courantes

Certaines menaces de cybersécurité courantes comprennent :

* Attaques par relais
* Attaques par rejeu
* Attaques de falsification de requête intersite (CSRF ou XSRF)
* Attaques par force brute
* <Tooltip tip="Suspicious IP Throttling : forme de protection contre les attaques qui protège votre locataire contre les tentatives de connexion suspectes visant trop de comptes à partir d’une même adresse IP." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Suspicious+IP+throttling">Limitation du trafic provenant d’IP suspectes</Tooltip>
* Attaques par bourrage d’identifiants
* Attaques par validation de listes

Auth0 propose des [fonctionnalités de protection contre les attaques](/fr-CA/docs/secure/attack-protection) qui peuvent aider à contrer certains types d’attaques.

<div id="bucket-brigade-attacks">
  ## Attaques par relais
</div>

Un type de menace est l’attaque par relais, parfois appelée attaque de type « man-in-the-middle », où l’attaquant s’interpose entre deux parties. Chaque partie croit communiquer au moyen d’une connexion privée, alors que l’échange est en réalité contrôlé par l’attaquant tiers. Pour que ce type d’attaque réussisse, l’attaquant doit établir une authentification mutuelle entre les deux parties.

Habituellement, les attaques par relais impliquent que l’attaquant utilise un routeur WiFi pour intercepter les communications d’un utilisateur. L’utilisateur se connecte au routeur de l’attaquant, puis visite un site Web et s’y connecte à l’aide de ses identifiants confidentiels. L’attaquant enregistre alors les identifiants de connexion de cet utilisateur, qu’il peut ensuite utiliser pour se faire passer pour lui.

Certaines attaques par relais peuvent aussi modifier les données transmises entre l’application et le serveur. Les attaques peuvent provenir de logiciels d’essai sur de nouveaux PC et de logiciels préinstallés, d’outils de mise à jour logicielle et d’autres vulnérabilités logicielles. Dans le pire des cas, cela pourrait entraîner l’exécution de code à distance, l’ajout de portes dérobées dans le système, l’installation de logiciels malveillants, etc. Cela pourrait aussi mener à la compromission d’autres actifs du réseau.

Pour aider à se protéger contre ce type d’attaque, il est important d’utiliser un chiffrement fort et une authentification entre l’application et le serveur. Grâce au chiffrement, le serveur authentifie la requête de l’application en présentant un certificat numérique, et ce n’est qu’ensuite que la connexion peut être établie. Par exemple, HTTPS utilise la couche SSL (Secure Sockets Layer) du navigateur pour masquer le trafic Web. Pour déchiffrer HTTPS, un attaquant devrait obtenir les clés utilisées pour chiffrer le trafic réseau.

Pour la configuration de TLS sur vos serveurs, nous recommandons d’utiliser les [recommandations OpSec de Mozilla](https://wiki.mozilla.org/Security/Server_Side_TLS), qui utilisent TLSv1.2. Mozilla fournit aussi un [générateur de configuration SSL](https://mozilla.github.io/server-side-tls/ssl-config-generator/) ; pour l’utiliser, choisissez d’abord la plateforme sur laquelle votre serveur s’exécute, puis la configuration la plus moderne en fonction de ce que vos applications peuvent prendre en charge. Les configurations les plus modernes offrent des suites de chiffrement plus robustes pour aider à prévenir les attaques.

<div id="replay-attacks">
  ## Attaques par rejeu
</div>

Les attaques par rejeu (ou par répétition) permettent aux attaquants de :

* Accéder à un réseau et à des renseignements qui n’auraient pas été facilement accessibles autrement
* Dupliquer une transaction

Il s’agit d’attaques contre un protocole de sécurité qui consistent à rejouer des transmissions de données d’un autre expéditeur vers le système récepteur visé. Ces attaques amènent les participants à croire, à tort, que la transmission des données a été effectuée avec succès.

Il est possible d’éviter les attaques par rejeu en utilisant des jetons de session. Toutefois, si ces identifiants sont volés à partir du stockage local (par exemple lors d’une attaque XSS), il existe des moyens d’empêcher qu’une personne conserve un jeton valide indéfiniment :

* Définir une courte durée d’expiration pour les jetons
* Prévoir un moyen d’ajouter à la DenyList les jetons qui ont été utilisés (et possiblement même les utilisateurs)
* Utiliser des mots de passe à usage unique

La spécification [JWT](/fr-CA/docs/secure/tokens/json-web-tokens) fournit le champ `jti` comme moyen de prévenir les attaques par rejeu. Bien que les jetons Auth0 ne renvoient pas actuellement le `jti`, vous pouvez ajouter des jetons à la DenyList à l’aide du `jti` afin d’empêcher qu’un jeton soit utilisé plus d’un certain nombre de fois. Vous mettez ainsi en œuvre un mécanisme semblable à un <Tooltip tip="Nonce : nombre arbitraire émis une seule fois dans un protocole d’authentification afin de détecter et de prévenir les attaques par rejeu." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=nonce">nonce</Tooltip> (considérez la signature du jeton comme le nonce). Si un jeton est volé ou s’il est utilisé plus de fois que le nombre autorisé, il doit être ajouté à la DenyList. Cela empêche l’utilisation malveillante d’un jeton valide. Une fois le jeton expiré, l’attaquant ne pourra plus usurper l’identité de l’utilisateur.

Vous pouvez aussi éviter les attaques par rejeu en utilisant des mots de passe à usage unique. Avec Auth0, vous pouvez utiliser l’authentification <Tooltip tip="Passwordless : forme d’authentification qui ne repose pas sur un mot de passe comme premier facteur." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Passwordless">Passwordless</Tooltip>, qui repose sur des codes à usage unique et des liens envoyés par courriel plutôt que sur des mots de passe traditionnels. Auth0 offre aussi l’<Tooltip tip="Authentification multifacteur (MFA) : processus d’authentification de l’utilisateur qui utilise un facteur en plus du nom d’utilisateur et du mot de passe, comme un code envoyé par SMS." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=multi-factor+authentication">authentification multifacteur</Tooltip> (MFA), qui utilise des mots de passe à usage unique comme deuxième facteur d’authentification pouvant être envoyés par notification push et par message texte.

<div id="cross-site-request-forgery">
  ## Falsification de requête intersite
</div>

Une attaque de falsification de requête intersite (CSRF ou XSRF) se produit lorsqu’un programme malveillant amène le navigateur Web d’un utilisateur à effectuer une action non souhaitée sur un site de confiance où l’utilisateur est actuellement authentifié. Ce type d’attaque cible plus précisément les requêtes qui modifient l’état afin de déclencher une action plutôt que d’obtenir des données utilisateur, puisque l’attaquant n’a aucun moyen de voir la réponse à la requête falsifiée.

Une façon de vérifier les requêtes envoyées consiste à utiliser le paramètre [state](/fr-CA/docs/secure/attack-protection/state-parameters) du protocole <Tooltip tip="OAuth 2.0 : Cadre d’autorisation qui définit les protocoles et les flux d’autorisation." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> pour valider la réponse.

<div id="learn-more">
  ## En savoir plus
</div>

* [Jetons](/fr-CA/docs/secure/tokens)
* [Protection contre les attaques](/fr-CA/docs/secure/attack-protection)
* [Conseils de sécurité généraux](/fr-CA/docs/secure/security-guidance/tips)