Fake account registrations and promotion abuse cost businesses real money. WAF's Risk Detection feature checks phone numbers submitted in registration or logon requests against a built-in mobile phone number reputation library—comparing the raw number or its MD5 hash—and takes action on suspicious traffic before it reaches your application.
Prerequisites
Before you begin, ensure that you have:
Added your web services to WAF on the Website Configuration page. For more information, see Website configuration overview.
Enabled bot management and created a web protection template or an app protection template.
Billing
Charges apply only when traffic matches a configured rule—at USD 0.007 per hit. If you enable Risk Detection but leave rules unconfigured, or if no traffic matches your rules, no charges apply.
Risk Detection charges appear in your WAF bill. Bills are generated daily.
How it works
Risk Detection rules follow a three-step flow:
Extract — WAF reads the phone number from the logon or registration request using the location and field name you configure in Account Extraction.
Detect — WAF compares the number (or its MD5 hash) against the reputation library and evaluates which Risk Tags apply.
Act — When a request matches a Risk Tag at or above the selected risk level, WAF applies the action you configured.
Configure Fraud Detection
Account Extraction
Tell WAF where to find the phone number in the request. Set the Account Type and Location, then specify the field name. Add up to five conditions; WAF evaluates them with a logical OR.
Example: A logon request uses the GET method with parameters username=158*&password=*. Set Location to Query Parameter and enter username for Parameter Name. WAF extracts the value of username for reputation lookup.
Risk tags
Each risk tag represents a phone number behavior pattern. WAF matches each tag independently. The default risk level for all tags is High; you can also match at Medium-high or Medium.
Risk tag | What it flags |
Suspicious Sock Puppet Account | A number that appears to originate from a third-party platform rather than an individual user |
Fraud Risk | A number with a history of fraudulent activity |
Spam User Registration | A number used with automated tools to register accounts for marketing campaigns |
Marketing Fraud | A number used to abuse promotions—for example, claiming coupons with multiple accounts |
Auto-purchase Bot | A number used for ticket grabbing or flash sale automation |
Rule type
Select whether to target suspected bots or confirmed malicious bots:
Suspected Bot — Exhibits some crawler characteristics but lacks direct evidence of malicious intent. Use this type when you want to challenge borderline traffic before blocking it.
Malicious Bot — An automated program with clear evidence of attack, data theft, or other malicious activity. Use this type to apply stronger enforcement actions.
Actions
Action | Behavior |
Block | Blocks the request and returns a block page. By default, WAF returns its preconfigured block page. To show a custom page, see Configure a custom block page. |
Monitor | Records the request in logs without blocking it. Use Monitor when testing a new rule: query logs in WAF to review hits and check for false positives, then switch to an enforcement action after confirming no false positives are generated. |
JavaScript Validation | Returns a JavaScript snippet. A normal browser executes the snippet automatically, after which WAF allows subsequent requests from that client for 30 minutes without further challenges. Non-executing clients are blocked. Not available for app protection. |
Slider CAPTCHA | Presents a slider verification page. After the client passes, WAF allows subsequent requests for 30 minutes. Clients that fail are blocked. |
Strict Slider CAPTCHA Verification | Presents a slider verification page for every request. After passing, WAF allows only that single request—no 30-minute window applies. |
Add Tag | Adds a custom header containing the rule type, rule ID, and Web UMID to the request, then forwards it to the origin server. Your backend risk control system reads this header and applies business-side logic—for example, flagging the account for manual review or blocking the transaction at the application layer. |
Canary release
Roll out a new rule to a subset of traffic before full deployment. Enable Canary Release, then set the Dimension and Canary Release Proportion.
Available dimensions: IP, Custom Header, Custom Parameter, Custom Cookie, Session, Web UMID.
WAF applies the rule to all traffic from objects that trigger the canary threshold for the selected dimension—not to a random percentage of all requests. For example, with IP as the dimension, every request from an IP that triggers the canary rule is subject to the protection rule.
Effective mode
Mode | When to use |
Permanently Effective (default) | Keep the rule active whenever the protection template is enabled. |
Fixed Schedule | Activate the rule for a one-time window in a specific time zone—useful for enabling stricter rules at the start of an event without giving attackers advance notice. |
Recurring Schedule | Activate the rule during a set window each day in a specific time zone—useful for recurring events that require stricter protection during peak periods, or for testing rules during low-traffic hours. |