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

> Describes different types of cyberattacks and what steps can be taken to prevent them.

# Prevent Common Cybersecurity Threats

Some common cybersecurity threats include:

* Bucket brigade attacks
* Replay attacks
* Cross-site Request Forgery (CSRF or XSRF) attacks
* Brute-force attacks
* <Tooltip tip="Suspicious IP Throttling: Form of attack protection that protects your tenant against suspicious logins targeting too many accounts from a single IP address." cta="View Glossary" href="/docs/glossary?term=Suspicious+IP+throttling">Suspicious IP throttling</Tooltip>
* Credential stuffing attacks
* List validation attacks

Auth0 has [attack protection features](/docs/secure/attack-protection) that can shield against certain types of attacks.

## Bucket brigade attacks

One type of threat is a bucket brigade attack, sometimes called a "man-in-the-middle" attack, where the attacker gets between two parties. Each party thinks they are interacting over a private connection, but the interaction is actually being controlled by the third-party attacker. For this type of attack to succeed the attacker must create mutual authentication between both parties.

Usually, bucket brigade attacks involve the attacker using a WiFi router to intercept a user's communication. The user connects to the attacker's router then visits a website and logs in with their confidential credentials. The attacker saves that user's login credentials for which they can then use to impersonate the user.

Some bucket brigade attacks can also modify the data transmitted between the application and the server. Attacks can occur from new PC trial and preinstalled software, software update tools, and other software vulnerabilities. In a worst-case scenario, this could result in remote code execution, backdooring the system, installing malware, and so on. This could also lead to the compromise of other network assets.

To help defend against this type of attack it is important to use strong encryption and authentication between the application and the server. Using encryption the server authenticates the application's request by presenting a digital certificate, and only then can the connection be established. For example, HTTPS uses the secure sockets layer (SSL) capability of the browser to mask web traffic. To decrypt HTTPS, an attacker would have to obtain the keys used to encrypt the network traffic.

With the configuration of TLS on your servers, we suggest using the [Mozilla OpSec recommendations](https://wiki.mozilla.org/Security/Server_Side_TLS) which use TLSv1.2. Mozilla also provides an [SSL Configuration Generator](https://mozilla.github.io/server-side-tls/ssl-config-generator/), to use this first choose which platform your server is running and then choose the most modern configuration based on what your application base can support. The more modern configurations provide stronger ciphers to help prevent attacks.

## Replay attacks

Replay (or playback) attacks allow attackers to:

* Gain access to a network and information which would not have been easily accessible
* Complete a duplicate transaction

These are attacks on the security protocol using replays of data transmission from a different sender into the intended receiving system. The attacks fool the participants into believing they have successfully completed the data transmission.

Replay attacks can be avoided by using session tokens. However, if these credentials are stolen from local storage (like during an XSS attack), there are ways to prevent someone from holding on to a valid token forever:

* Set a short expiration time for tokens
* Provide a way to add tokens to the DenyList that have been used (and possibly even the users)
* Use one-time passwords

The [JWT](/docs/secure/tokens/json-web-tokens) spec provides the `jti` field as a way to prevent replay attacks. Though Auth0 tokens currently don't return the `jti`, you can add tokens to the DenyList using the `jti` to prevent a token being used more than a specified number of times. In this way, you are implementing something similar to a <Tooltip tip="Nonce: Arbitrary number issued once in an authentication protocol to detect and prevent replay attacks." cta="View Glossary" href="/docs/glossary?term=nonce">nonce</Tooltip> (think of the token's signature as the nonce). If a token gets stolen or it gets used more than the specified number of times, it should be added to the DenyList. This prevents a valid token from being used maliciously. Once the token expires, the attacker will no longer be able to impersonate the user.

You can also avoid replay attacks by using one-time passwords. With Auth0, you can use <Tooltip tip="Passwordless: Form of authentication that does not rely on a password as the first factor." cta="View Glossary" href="/docs/glossary?term=Passwordless">Passwordless</Tooltip> Authentication, which relies on single-use codes and email links instead of traditional passwords. Auth0 also provides <Tooltip tip="Multi-factor authentication (MFA): User authentication process that uses a factor in addition to username and password such as a code via SMS." cta="View Glossary" href="/docs/glossary?term=multi-factor+authentication">multi-factor authentication</Tooltip> (MFA) which uses one-time passwords as a second-factor authentication which can be sent via push notifications and texts.

## Cross-site Request Forgery

A Cross-site Request Forgery (CSRF or XSRF) attack occurs when a malicious program causes a user's web browser to perform an unwanted action on a trusted site on which the user is currently authenticated. This type of attack specifically targets state-changing requests to initiate a type of action instead of getting user data because the attacker has no way to see the response of the forged request.

One way to verify the requests that are being sent is to utilize the <Tooltip tip="OAuth 2.0: Authorization framework that defines authorization protocols and workflows." cta="View Glossary" href="/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> protocol [state parameter](/docs/secure/attack-protection/state-parameters) to authenticate the response.

## Learn more

* [Tokens](/docs/secure/tokens)
* [Attack Protection](/docs/secure/attack-protection)
* [General Security Tips](/docs/secure/security-guidance/tips)