--- title: Using the deception action summary: null url: >- https://www.fastly.com/documentation/guides/next-gen-waf/rules/using-the-deception-action --- To help defend your web applications from Account Takeover (ATO) attacks (e.g., [credential stuffing](https://owasp.org/www-community/attacks/Credential_stuffing)), you can add rules that use the **Deception** action type. When the Next-Gen WAF identifies POST requests to login forms that match these rules, the WAF prevents the requests from accessing your origin and returns an invalid credentials page. This response tricks attackers into believing their attack failed due to incorrect credentials, when in reality the WAF actually blocked them. The deception response discourages attackers from continuing their account takeover attempts to save resources and time. ## Prerequisites To use the deception action, be sure you have the following prerequisites in place: * The [deception](https://www.fastly.com/documentation/guides/next-gen-waf/rules/about-rules/#deception) rule action type is not available for the [Essential or Professional platforms](https://docs.fastly.com/products/fastly-next-gen-waf#feature-availability). * You must have an [Edge WAF deployment](https://docs.fastly.com/products/fastly-next-gen-waf#deployment-types). The other deployment types do not support the deception action. * [Dynamic backends](https://www.fastly.com/documentation/guides/next-gen-waf/setup-and-configuration/edge-deployment/ngwaf-control-panel/maintaining-edge-waf-deployments-using-the-next-gen-waf-control-panel/#checking-whether-dynamic-backends-are-enabled) must be enabled. If they are not enabled, ask [customer support](https://support.fastly.com) to enable them for you. ## Limitations and considerations When working with the deception action, keep in mind the following: * [Advanced rate limiting rules](/guides/next-gen-waf/rules/working-with-advanced-rate-limiting-rules/) and [request rules](/guides/next-gen-waf/rules/working-with-request-rules/) support the deception action at the site-level (workspace-level) only. Other rule types don't support the deception action. * Deception rules only take action on POST requests to login forms where the password field is named `password`, `passwd`, `pass`, or `pw`. ## How it works Let's say you have a deception rule protecting your web application's login page from POST requests that use [known compromised credentials](/guides/next-gen-waf/signals/using-system-signals/#bots-compromised-password). When the Next-Gen WAF identifies a request that meets the rule's conditions, the WAF: * tags the request with the [`Deception Response`](/guides/next-gen-waf/signals/using-system-signals/#anomalies-deception) signal. * obtains the invalid credentials page from your web application. * forwards the invalid credentials page to the attacker. This tricks the attacker into thinking that their login attempt failed and that the WAF did not block them. ## Examples The following examples demonstrate how to configure deception rules to prevent ATO attacks. Be aware that values (e.g., paths) used in these examples may not be the same as those used by your particular web application. ### Example request rule This example demonstrates how to configure a [request rule](/guides/next-gen-waf/rules/working-with-request-rules) that will deceive attackers attempting to use suspected bad bots to log in to a web application. The request rule requires two conditions: * The request must be tagged with the `Suspected Bad Bot` signal. * The path of the request needs to be `/login`. > **HINT:** A condition requiring the HTTP method to be POST is not required. The Next-Gen WAF won't take action on matching requests unless the HTTP method is POST. The rule must have an **Action type** of **Deception** and a **Deception type** of **Invalid Login Response**. ### Example advanced rate limiting rule This example demonstrates how to configure an [advanced rate limiting rule](/guides/next-gen-waf/rules/working-with-advanced-rate-limiting-rules) that will deceive attackers attempting to use known compromised credentials to log in to a web application after they exceed a threshold. The advanced rate limiting rule requires two conditions: * The request must be tagged with the `Compromised Password` signal. * The path of the request needs to be `/login`. > **HINT:** A condition requiring the HTTP method to be POST is not required. The Next-Gen WAF won't take action on matching requests unless the HTTP method is POST. The rule must also: * set the **Client key** to **IP address (default)**. Client key specifies how the WAF should identify an individual client. * define threshold tracking behavior by setting **Threshold signal** to the **Rate Limit ATO** custom signal and leaving the default **Threshold** and **Interval** values. * define rate limiting behavior by setting **Action type** to **Deception** and **Deception type** to **Invalid Login Response**. ## Related content * [Working with advanced rate limiting rules](/guides/next-gen-waf/rules/working-with-advanced-rate-limiting-rules) * [Working with request rules](/guides/next-gen-waf/rules/working-with-request-rules)