Different business applications have different risk profiles and false positive tolerances. The application protection feature provides two protection modes, three built-in detection rule groups, and a whitelist mechanism so you can tune coverage and suppression independently for each application group.
Protection modes
Application protection runs in one of two modes:
Monitor: Detects attack behavior and generates alerts, but does not block requests. Alerts show the action as Monitor.
Block: Detects and blocks attack behavior, and monitors important operations. When an attack is blocked, an alert is generated with the action set to Block.
When you create an application group, the protection mode defaults to Monitor.
Move from Monitor to Block
Run a new application group in Monitor mode before enabling blocking. This lets you observe traffic patterns and resolve false positives without disrupting legitimate business requests.
Tuning workflow:
Deploy the application group in Monitor mode. We recommend running it for 2 to 5 days before switching to Block.
Review alerts daily to identify false positives—attacks detected on requests that are actually legitimate traffic.
For each false positive, add a whitelist rule to suppress the alert. See Configure a protection whitelist.
When no new false positives appear, switch the protection mode to Block.
Protection policy groups
A protection policy group is a set of attack detection rules applied to an application group. All rules in a group share the same detection mode.
Built-in policy groups
Three built-in groups are available:
| Policy group | Detection mode | Use when |
|---|---|---|
| Business First (default loose) | Loose | False positive rate is a top concern; only known attack signatures must be detected |
| Normal Operations (default standard) | Standard | General O&M scenarios with a balance of protection and availability |
| Protection First (default strict) | Strict | Major events or high-risk periods where catching hidden attacks takes priority |
Detection modes
Detection modes control how aggressively rules match attack patterns. Listed in ascending order of both protection capability and false positive rate:
Loose: Matches only known attack signatures. Very low false positive rate.
Standard (default): Matches common attack patterns and applies some generalized inference. Suitable for daily O&M.
Strict: Detects more hidden attack behaviors. Suitable for major event support scenarios, but has a certain risk of false positives.
Create a protection policy group
If none of the built-in policy groups fit your needs, create a custom one. To base a new group on an existing configuration, click Copy in the Actions column for that group.
Log on to the Security Center consoleSecurity Center consoleSecurity Center console.Log on to the Security Center console.
In the navigation pane on the left, choose Protection Configuration > Application Protection. In the upper-left corner, select the region where your asset is located: Chinese Mainland or Outside Chinese Mainland.
On the Application Configurations tab, click Management Settings in the upper-right corner.
In the Management Settings panel, on the Manage Protection Policy tab, click Create Protection Policy Group.
In the Create Protection Policy Group panel, enter a name, select an application language, and click Select to the right of Threat Type.
In the Select Threat Type panel, select the detection types to include, set the Detection Mode for each type, and click OK.
Tip: If alerts for a specific attack type, such as SQL injection, contain many false positives, set the detection mode for that type to Loose rather than adjusting the entire group.
Click OK.
Configure a protection whitelist
A protection whitelist rule suppresses alerts for specific traffic patterns that your application generates legitimately. Use whitelists when Monitor mode consistently flags the same legitimate requests as attacks.
Note: Whitelist rules work best for stable, predictable traffic patterns (for example, a fixed internal service URL or a known parameter value). For broader tuning needs—such as reducing detection strength for an entire attack category—adjust the detection mode on the policy group instead.
Add a whitelist rule from an alert
If an alert is confirmed as a false positive, add it directly to the whitelist. A rule is automatically created from the alert details and applied to the application group that contains the affected process.
For steps, see Add an alert to a whitelist.
Create a whitelist rule manually
Manually created rules let you suppress multiple detection types across multiple application groups in a single rule.
Log on to the Security Center consoleSecurity Center consoleSecurity Center console.Log on to the Security Center console.
In the navigation pane on the left, choose Protection Configuration > Application Protection. In the upper-left corner, select the region where your asset is located: Chinese Mainland or Outside Chinese Mainland.
On the Application Configurations tab, click Management Settings in the upper-right corner. Alternatively, on the Attack Alerts tab, click Protection Whitelist.
In the Management Settings panel, on the Protection Whitelist tab of the Manage Protection Policy tab, click Create Whitelist.
In the Create Whitelist panel, configure the rule parameters and click OK.
Match method options:
| Match method | Behavior | Best for |
|---|---|---|
| Exact Match | Suppresses alerts only when the transmitted content is identical to the match content | A specific known-safe parameter value or payload |
| Partial Match | Suppresses alerts when the transmitted content contains the match content | A recurring substring in false-positive payloads |
| Prefix Match | Suppresses alerts when the transmitted content starts with the match content | A URL path prefix shared by multiple legitimate endpoints |
| Suffix Match | Suppresses alerts when the transmitted content ends with the match content | A file extension or URL suffix common to legitimate requests |
Content to Match: Use the value of Malicious Characteristics, Specified Parameters, or Request URL from the alert details page as the match content.
Example: If an internal health-check endpoint at /api/health?token=<value> repeatedly triggers SQL injection alerts, use Prefix Match with /api/health as the match content. This suppresses alerts for all requests to that path without exposing other routes.
View and manage whitelist rules
Log on to the Security Center consoleSecurity Center consoleSecurity Center console.Log on to the Security Center console.
In the navigation pane on the left, choose Protection Configuration > Application Protection. In the upper-left corner, select the region where your asset is located: Chinese Mainland or Outside Chinese Mainland.
On the Application Configurations tab, click Management Settings in the upper-right corner. Alternatively, on the Attack Alerts tab, click Protection Whitelist.
In the Management Settings panel, on the Protection Whitelist tab of the Manage Protection Policy tab, view the list of whitelist rules.
From the list, you can:
Enable or disable: Toggle the switch in the Rule Switch column.
Edit or delete: Click Edit or Delete in the Actions column.
Modify the protection policy for an application group
On the Application Configurations tab of the Application Protection page, click Protection Policy in the Actions column for the application group.
In the Protection Policy panel, modify Protection Status, Protection Mode, Protection Policy Group, Detection Policy, or Common Settings as needed.
Click OK.
Batch operations
To apply changes to multiple application groups at once, select one or more groups on the Application Configurations tab and use the following actions:
| Action | Effect |
|---|---|
| Protect All | Changes the protection mode to Block for all selected groups |
| Monitor All | Changes the protection mode to Monitor for all selected groups |
| Cancel Protection | Disables all detection and blocking for selected groups; no attack behavior is detected or blocked |
| Enable All | Re-enables the selected groups |