The waf plug-in uses a ModSecurity-based rules engine to block suspicious requests. It supports the OWASP ModSecurity Core Rule Set (CRS) to provide basic protection for websites.
The waf plug-in uses open source ModSecurity rules. The default rules are static and cannot identify the latest security risks or update the rule set in real time. For stronger protection, enable Web Application Firewall (WAF) protection for Cloud-native API Gateway instances. For more information, see Enable WAF.
Plug-in type
Security protection.
Fields
|
Field |
Data type |
Required |
Default value |
Description |
|
useCRS |
bool |
No |
false |
Specifies whether to enable OWASP CRS. For details, see coreruleset. |
|
secRules |
array of string |
No |
- |
Custom protection rules for the waf plug-in. For syntax details, see ModSecurity documentation. |
Configuration examples
Use the default rule
Enable the default rule to block suspicious requests:
useCRS: true
Enable the default rule in detection-only mode without blocking requests:
useCRS: true
secRules:
- "SecRuleEngine DetectionOnly"
Use custom protection rules
useCRS: true
secRules:
- "SecRule REQUEST_URI \"@streq /admin\" \"id:101,phase:1,t:lowercase,deny\""
- "SecRule REQUEST_BODY \"@rx maliciouspayload\" \"id:102,phase:2,t:lowercase,deny\""
The preceding rules block the following requests:
curl http://example.com/admin
curl http://example.com -d "maliciouspayload"
Enable protection rules for a specific route or domain name
useCRS: true
secRules:
- "SecRule REQUEST_URI \"@streq /admin\" \"id:101,phase:1,t:lowercase,deny\""
- "SecRule REQUEST_BODY \"@rx maliciouspayload\" \"id:102,phase:2,t:lowercase,deny\""
Apply the following plug-in configurations to the route-1 route:
secRules:
- "SecAction \"id:102,phase:1,deny\""
Apply the following plug-in configurations to the *.example.com and test.com domain names:
secRules:
- "SecAction \"id:102,phase:1,pass\""
-
The
route-1route is defined when the Cloud-native API Gateway route is created. If a client request matches this route, the route-level rules take effect. -
The
*.example.comandtest.comdomain names match against domain names in requests. If a client request matches one of these domain names, the domain-level rules take effect. -
Rules take effect in the order they are configured. Once a rule matches, subsequent rules are skipped.