OpenResty Edge WAF: Enable, Test, and Block Attacks

OpenResty Edge ships with a built-in, high-performance WAF that you enable per application from the web console: pick the rule sets, trial them in log-only mode, check the hit logs, then switch the action to blocking with a 403 response — all published to every gateway server without any reload or restart.

OpenResty Edge’s WAF engine is also several times faster than open-source WAFs like ModSecurity and lua-resty-waf; see the WAF benchmark against ModSecurity for the numbers. This tutorial focuses on the console operations: enabling, testing, tuning, and extending the WAF step by step.

Enable the WAF for an Application in Log-Only Mode

Let’s go to the web console of OpenResty Edge. This is our sample deployment of the console. Every user has their own deployment.

We use our continuing sample application for the test-edge.com domain.

Let’s enter this application.

Go to the Page Rules page.

We already have a reverse proxy page rule set up in an earlier tutorial.

Now let’s enable some WAF rulesets.

Edit the page rules.

Click the WAF switch to enable it.

Here we can choose the WAF rulesets to enable.

Here we just keep the default rulesets.

Select the action for the requests hitting the WAF rules.

The Log only action helps test the WAF rule itself without worrying about affecting the requests.

Save the rule.

We need to make a new configuration release to push out our new changes, as always.

Click on this button.

Ship it!

Our new release is now synchronized to all our gateway servers.

Now the change has been pushed to all the gateway clusters and servers.

Our configuration changes do NOT require server reload, restart, or binary upgrade. So it’s very efficient and scalable.

Send a Test Attack and Review the WAF Logs

Let’s send a malicious request attempting a SQL injection.

The request returned the default index page of the origin site. It was to be expected since we chose to log hits only.

Let’s check the WAF hit Logs in the web console.

We can see that the rule was indeed hit and logged.

This part shows the details of the individual requests caught by the WAF.

Click the Check Rule button to see the details of the WAF rule matched.

Show the rule definition in the Edge language.

Disable and Re-enable Individual WAF Rules

If you find any false positives, you can toggle this switch to disable the corresponding WAF rule individually.

Disabled rules will be displayed on the WAF Config page.

Here is the list of disabled WAF rules.

And this is the WAF rule we just disabled.

Click the Delete button to re-enable the rule.

Add a WAF Whitelist to Save CPU Cycles

Furthermore, you can add a WAF white-list to skip requests which should bypass the WAF to save CPU cycles.

For example, static assets generally don’t need WAF filtering. Skipping those resources can reduce the overhead on your servers.

Return 403 on a WAF Hit: Sensitivity and Risk-Score Thresholds

This time, let’s change the “Log only” action to something else. Like returning a 403 error response.

Go to the Page Rules page.

Edit the page rule again.

Change the action.

We’ll block malicious requests this time.

Here we can set the sensitivity level.

Alternatively, we can also set a score number directly.

It is the sum of the risk scores of all the matched WAF rules. The action will not run until the total score threshold is reached.

Save the rule.

Release the configuration changes again.

Verify the 403 Block in the WAF Logs

Send the malicious request again.

The server returned a “403 Forbidden” response this time.

Check out the WAF Logs page again.

The action logged is indeed “Block with HTTP code 403” here.

Create Your Own WAF Rule Set in EdgeLang

The WAF platform is very flexible and extensible. You can also create your own WAF rulesets.

Go to the Global Config page.

Click the “Global WAF” menu item.

Click the New Rule Set button.

Enter the ruleset name here, and definition here.

And also custom WAF rules in our Edge language, or Edgelang for short.

And then we can save it.

Quit this page.

However many rule sets you enable, the WAF stays fast: OpenResty Edge combines all the rules’ regular expressions into a single state machine and scans each request only once. See how the OpenResty Edge WAF outperforms ModSecurity for the implementation details and benchmark numbers.

FAQ: WAF on OpenResty

Does open-source OpenResty have a built-in WAF?

No. Open-source OpenResty ships no WAF module. The WAF in this tutorial is a feature of OpenResty Edge, the commercial gateway product built on OpenResty, which includes the managed rule sets, log-only mode, WAF logs, and blocking actions shown above out of the box.

Can I run ModSecurity on open-source OpenResty?

There is no official ModSecurity module for OpenResty. You would have to compile libmodsecurity and the third-party nginx connector against OpenResty’s bundled nginx yourself, and ModSecurity’s original vendor ended its support in 2024, handing the project over to community maintenance. It is a fully self-supported path today.

Is lua-resty-waf still an option for OpenResty?

Not really. lua-resty-waf has been unmaintained for years and is not recommended for new production deployments. For a maintained WAF on the OpenResty stack, the practical option is the built-in WAF in OpenResty Edge, which is the engine this tutorial configures.

How do I test WAF rules without blocking real traffic?

Set the WAF action to “Log only” when enabling the rule sets. Requests that match rules pass through to the origin unchanged, but every hit is recorded in the WAF logs, where the Check Rule button shows exactly which rule matched. Once the rules look right, switch the action to blocking and release the configuration.

How does the OpenResty Edge WAF decide when to block a request?

Every matched WAF rule carries a risk score, and the scores of all matched rules are summed per request. The block action fires only when the total reaches the threshold, which you set either by choosing a sensitivity level or by entering a score number directly.

How do I disable a single WAF rule in OpenResty Edge?

If a rule keeps matching legitimate traffic, toggle off just that rule from the WAF logs; the rest of the rule set keeps running. Disabled rules are listed on the WAF Config page, where deleting the entry re-enables the rule. You can also whitelist requests that don’t need filtering at all, such as static assets, which saves CPU cycles too.

What is OpenResty Edge

OpenResty Edge is our all-in-one gateway software for microservices and distributed traffic architectures. It combines traffic management, private CDN construction, API gateway, security, and more to help you easily build, manage, and protect modern applications. OpenResty Edge delivers industry-leading performance and scalability to meet the demanding needs of high concurrency, high load scenarios. It supports scheduling containerized application traffic such as K8s and manages massive domains, making it easy to meet the needs of large websites and complex applications.

If you like this tutorial, please subscribe to this blog site and/or our YouTube channel. Thank you!

About The Author

Yichun Zhang (Github handle: agentzh), is the original creator of the OpenResty^® open-source project and the CEO of OpenResty Inc..

Yichun is one of the earliest advocates and leaders of “open-source technology”. He worked at many internationally renowned tech companies, such as Cloudflare, Yahoo!. He is a pioneer of “edge computing”, “dynamic tracing” and “machine coding”, with over 22 years of programming and 16 years of open source experience. Yichun is well-known in the open-source space as the project leader of OpenResty^®, adopted by more than 40 million global website domains.

OpenResty Inc., the enterprise software start-up founded by Yichun in 2017, has customers from some of the biggest companies in the world. Its flagship product, OpenResty XRay, is a non-invasive profiling and troubleshooting tool that significantly enhances and utilizes dynamic tracing technology. And its OpenResty Edge product is a powerful distributed traffic management and private CDN software product.

As an avid open-source contributor, Yichun has contributed more than a million lines of code to numerous open-source projects, including Linux kernel, Nginx, LuaJIT, GDB, SystemTap, LLVM, Perl, etc. He has also authored more than 60 open-source software libraries.