Skip to main content

Integrate with Coraza

With rapid development of technology, it has become increasingly crucial to secure APIs. APISIX supports the integration with Coraza by using coraza-proxy-wasm to provide reliable security protection and ensure the integrity and reliability of API services.

Coraza is an open-source, enterprise-grade, high-performance Web Application Firewall (WAF). It is designed to safeguard web applications against various cyber attacks by filtering and monitoring HTTP/HTTPS communications between web applications and the internet. Integrating with Coraza, APISIX significantly enhances APISIX's ability to protect upstream services.


Integration with Coraza

This guide will show you how to enable coraza-proxy-wasm to integrate APISIX with Coraza WAF to protect upstream services.

Prerequisite(s)

Download coraza-proxy-wasm

Download coraza-proxy-wasm from the release page and unzip it:

wget https://github.com/corazawaf/coraza-proxy-wasm/releases/download/0.6.0/coraza-proxy-wasm-0.6.0.zip
unzip coraza-proxy-wasm-0.6.0.zip
caution

The upstream 0.6.0 release notes warn that TinyGo runtime limitations can cause memory leaks and performance degradation. Test the module under expected traffic before using it in production.

Copy coraza-proxy-wasm.wasm into the /usr/local/bin directory:

docker cp coraza-proxy-wasm.wasm apisix-quickstart:/usr/local/bin/

Load coraza-proxy-wasm in APISIX

Update the config.yaml configuration file by adding coraza-proxy-wasm configurations:

docker exec apisix-quickstart /bin/bash -c "echo '
wasm:
plugins:
- name: coraza-filter
priority: 7999
file: /usr/local/bin/coraza-proxy-wasm.wasm
' >> /usr/local/apisix/conf/config.yaml"

name: the name of the APISIX plugin corresponding to coraza-proxy-wasm.

priority: the execution priority of the plugin.

file: the absolute path to coraza-proxy-wasm.

Reload APISIX for configuration changes to take effect:

docker exec apisix-quickstart apisix reload

Configure Specific Security Rules

Create a route and enable coraza-filter:

curl -i "http://127.0.0.1:9180/apisix/admin/routes/" -X PUT -d '
{
"id": "getting-started-waf",
"uri": "/anything/*",
"plugins": {
"coraza-filter": {
"conf": {
"directives_map": {
"default": [
"SecDebugLogLevel 9",
"SecRuleEngine On",
"SecRule REQUEST_URI \"@beginsWith /anything/archive\" \"id:101,phase:1,t:lowercase,deny\""
]
},
"default_directives": "default"
}
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"httpbin.org:80": 1
}
}
}'

SecDebugLogLevel: configure the debug log level. For details, see SecDebugLogLevel.

SecRuleEngine: configure the rules engine. For details, see SecRuleEngine.

SecRule: check the URI value of your HTTP request to see if the URI value begins with /anything/archive. If matched, the request will be rejected. For details, see SecRule.

Verify

Send a request to the route to verify if the HTTP request with a URI beginning with anything/archive will be rejected:

curl -i "http://localhost:9080/anything/archive/test"

You should receive an HTTP/1.1 403 Forbidden response.

Send a request to the route to verify if the HTTP request with a URI beginning with anything will be allowed:

curl -i "http://localhost:9080/anything/public"

You should receive an HTTP/1.1 200 OK response.

Configure OWASP Core Rule Set

You can also configure the entire OWASP Core Rule Set (CRS) on the route as such:

curl -i "http://127.0.0.1:9180/apisix/admin/routes/" -X PUT -d '
{
"id": "getting-started-waf",
"uri": "/anything/*",
"plugins": {
"coraza-filter": {
"conf": {
"directives_map": {
"default": [
"SecDebugLogLevel 9",
"SecRuleEngine On",
"Include @crs-setup-conf",
"Include @owasp_crs/*.conf"
]
},
"default_directives": "default"
}
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"httpbin.org:80": 1
}
}
}'

❶ Include @crs-setup-conf to support CRS.

❷ Include all CRS rules. You could also include a specific rule, such as @owasp_crs/REQUEST-941-APPLICATION-ATTACK-XSS.conf. See all available rules.

Verify

Send a request with a potential XSS attack to the route:

curl -i "http://localhost:9080/anything/public" -H "Cookie: <body onload='alert(xss)'>"

You should receive an HTTP/1.1 403 Forbidden response and observe entries similar to the following in the APISIX error log:

Coraza: Warning. NoScript XSS InjectionChecker: HTML Injection [file "@owasp_crs/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [id "941160"] [ver "OWASP_CRS/4.14.0"] [uri "/anything/public"]
Coraza: Warning. Javascript method detected [file "@owasp_crs/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [id "941390"] [ver "OWASP_CRS/4.14.0"] [uri "/anything/public"]
Coraza: Access denied (phase 1). Inbound Anomaly Score Exceeded in phase 1 [file "@owasp_crs/REQUEST-949-BLOCKING-EVALUATION.conf"] [id "949111"] [ver "OWASP_CRS/4.14.0"] [uri "/anything/public"]

This verifies that the CRS rules are in effect to protect your route.

Next Steps

APISIX also supports the integration with Chaitin WAF. See the plugin documentation for configuration examples and deployment considerations.