Adding the ATP managed rule group to your web ACL - Amazon WAF, Amazon Firewall Manager, and Amazon Shield Advanced
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Adding the ATP managed rule group to your web ACL

To configure the ATP managed rule group to recognize account takeover activities in your web traffic, you provide information about how clients send login requests to your application. For protected Amazon CloudFront distributions, you also provide information about how your application responds to login requests. This configuration is in addition to the normal configuration for a managed rule group.

For the rule group description and rules listing, see Amazon WAF Fraud Control account takeover prevention (ATP) rule group.


The ATP stolen credentials database only contains usernames in email format.

This guidance is intended for users who know generally how to create and manage Amazon WAF web ACLs, rules, and rule groups. Those topics are covered in prior sections of this guide. For basic information about how to add a managed rule group to your web ACL, see Adding a managed rule group to a web ACL through the console.

Follow best practices

Use the ATP rule group in accordance with the best practices at Best practices for intelligent threat mitigation.

To use the AWSManagedRulesATPRuleSet rule group in your web ACL
  1. Add the Amazon managed rule group, AWSManagedRulesATPRuleSet to your web ACL, and Edit the rule group settings before saving.


    You are charged additional fees when you use this managed rule group. For more information, see Amazon WAF Pricing.

  2. In the Rule group configuration pane, provide the information that the ATP rule group uses to inspect login requests.

    1. For Use regular expression in paths, toggle this on if you want Amazon WAF to perform regular expression matching for your login page path specifications.

      Amazon WAF supports the pattern syntax used by the PCRE library libpcre with some exceptions. The library is documented at PCRE - Perl Compatible Regular Expressions. For information about Amazon WAF support, see Regular expression pattern matching in Amazon WAF.

    2. For Login path, provide the path of the login endpoint for your application. The rule group inspects only HTTP POST requests to your specified login endpoint.


      Matching for endpoints is case insensitive. Regex specifications must not contain the flag (?-i), which disables case insensitive matching. String specifications must start with a forward slash /.

      For example, for the URL, you could provide the string path specification /web/login. Login paths that start with the path that you provide are considered a match. For example /web/login matches the login paths /web/login, /web/login/, /web/loginPage, and /web/login/thisPage, but doesn't match the login path /home/web/login or /website/login.

    3. For Request inspection, specify how your application accepts login attempts by providing the request payload type and the names of the fields within the request body where the username and password are provided. Your specification of the field names depends on the payload type.

      • JSON payload type – Specify the field names in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation JavaScript Object Notation (JSON) Pointer.

        For example, for the following example JSON payload, the username field specification is /login/username and the password field specification is /login/password.

        { "login": { "username": "THE_USERNAME", "password": "THE_PASSWORD" } }
      • FORM_ENCODED payload type – Use the HTML form names.

        For example, for an HTML form with input elements named username1 and password1, the username field specification is username1 and the password field specification is password1.

    4. If you're protecting Amazon CloudFront distributions, then under Response inspection, specify how your application indicates success or failure in its responses to login attempts.


      ATP response inspection is available only in web ACLs that protect CloudFront distributions.

      Specify a single component in the login response that you want ATP to inspect. For the Body and JSON component types, Amazon WAF can inspect the first 65,536 bytes (64 KB) of the component.

      Provide your inspection criteria for the component type, as indicated by the interface. You must provide both success and failure criteria to inspect for in the component.

      For example, say your application indicates the status of a login attempt in the status code of the response, and uses 200 OK for success and 401 Unauthorized or 403 Forbidden for failure. You would set the response inspection Component type to Status code, then in the Success text box enter 200 and in the Failure text box, enter 401 on the first line and 403 on the second.

      The ATP rule group only counts responses that match your success or failure inspection criteria. The rule group rules act on clients while they have too high a failure rate among the responses that are counted. For accurate behavior by the rule group rules, be sure to provide complete information for both successful and failed login attempts.

      To see the rules that inspect login responses, look for VolumetricIpFailedLoginResponseHigh and VolumetricSessionFailedLoginResponseHigh in the rules listing at Amazon WAF Fraud Control account takeover prevention (ATP) rule group.

  3. Provide any additional configuration that you want for the rule group.

    You can further limit the scope of requests that the rule group inspects by adding a scope-down statement to the managed rule group statement. For example, you can inspect only requests with a specific query argument or cookie. The rule group will inspect only HTTP POST requests to your specified login endpoint that match the criteria in your scope-down statement. For information about scope-down statements, see Scope-down statements.

  4. Save your changes to the web ACL.

Before you deploy your ATP implementation for production traffic, test and tune it in a staging or testing environment until you are comfortable with the potential impact to your traffic. Then test and tune the rules in count mode with your production traffic before enabling them. See the section that follows for guidance.