What Are the OWASP Top 10, Core Rule Set (CRS), and ModSecurity?

repair Windows 11

Request sent to the site
        ↓
ModSecurity inspects it
        ↓
OWASP CRS rules are applied
        ↓
Normal or suspicious behavior?
        ↓
The request continues or may be blocked

This is an important point. You can have the ModSecurity module installed on your server without receiving the protection you expect. The engine must be active, the rules must be loaded, the important parts of requests must be inspected and the rules must be able to trigger actions.

ModSecurity has three main states for SecRuleEngine:

Off
DetectionOnly
On

In DetectionOnly mode, the rules run but blocking actions are not applied. The engine can detect something and log it without preventing the request from continuing. This is what I recommend when you are just getting started with ModSecurity and CRS, because you will see that they are very powerful and can even block you yourself. It happened to me: CRS blocked my WordPress editor, and I could no longer edit or update an article. That brings us to one of the most important points when using CRS.

Why not simply enable CRS in blocking mode?

Because CRS is deliberately general. It must be usable in front of a huge range of applications without knowing in advance how they work. WordPress, Nextcloud, a custom API and an online shop do not communicate in the same way.

Some applications also send data that can look like an attack when taken out of context. This is called a false positive. A WAF does not understand a page like a human; it mainly sees a URL, cookies, HTTP headers, a request body and strings of characters.

I cannot search for PowerShell on my WordPress site

On Assistouest.fr, I published an IT article containing a PowerShell command. To me, it is simply content explaining a Windows procedure. But part of that command looks like something an attacker might send to try to execute code on Windows Server. The firewall does not necessarily know that I am writing an article. It mainly sees the string of characters.

The false positives I encountered on my server

On my infrastructure, I have encountered several false-positive cases with ModSecurity and CRS.

These included some Nextcloud requests using WebDAV, WordPress content discussing PowerShell or Base64, and certain Cloudflare cookies such as cf_clearance.

The rule often detected something that looked like what it was searching for. The issue was simply that, in this specific context, the request was legitimate. That is where logs become essential for properly configuring CRS and ModSecurity.

A 403 is not enough to understand what happened

When ModSecurity blocks a request, the browser receives a 403 Forbidden response, indicating that the request was refused. On my infrastructure, when a behavior surprises me, I do not start by disabling the rule.

I start by finding out why it was triggered. The opposite is also true. The absence of a 403 does not mean that ModSecurity detected nothing.

A rule may have been triggered without the request being blocked.

This can happen when the engine is running in DetectionOnly mode, but also when the total suspicion level is not high enough to reach the blocking threshold.

The anomaly score: several small signals can trigger a rule

OWASP CRS uses a weighted anomaly score. When a rule matches something suspicious, it can add points to the transaction. Not all detections have the same importance. The official configuration uses different scores depending on rule severity, then compares the total with a blocking threshold.

Let’s deliberately use a simplified example. A first rule detects something slightly suspicious:

+ 3 points

A second rule finds something else suspicious:

+ 2 points

The total score becomes 5. If the blocking threshold is set to 5, the request can then be rejected.

Paranoia Levels: detect more and block without warning, or not

CRS also has several Paranoia Levels (PL). Level 1 is the default.

As you move up the levels, more rules are enabled and the checks gradually become stricter. This can improve the detection of certain behaviors.

But there is a trade-off: the more sensitive the rules become, the more you also increase the risk of false positives. This does not mean:

PL4 = better security

The right configuration is the one you can administer correctly.

A very high PL that later forces you to disable entire families of rules can be less useful than a more reasonable level that is properly tuned.

You will need to allow exactly what is legitimate

This is probably one of the least visible aspects of CRS. When a rule blocks a legitimate request, the easiest solution is to create an exception rather than disable the rule.

Imagine that an XSS rule causes a problem only when a particular WordPress field contains code intended for a technical article.

You could disable that rule everywhere.

The false positive disappears.

But the protection also disappears everywhere else on the site.

A better approach is to say:

This rule remains active everywhere

EXCEPT

For this specific field, in this feature and when necessary

CRS provides several exclusion mechanisms that let you limit an exception to a variable, a URL or a specific context, without removing the rule from the entire site.

You must test again after every exclusion

An exclusion fixes a problem. But if it is too broad, it can also create a weakness in the protection. That is why I then run regression tests.

On my installation, I used test requests corresponding to several families of SQL injection, XSS, LFI and RCE attempts, as well as access to certain sensitive files such as .env.

Can a WAF protect against a zero-day vulnerability?

This is also one of the most interesting benefits of CRS’s general rules. A zero-day is a newly discovered vulnerability for which a fix may not yet be available.

Obviously, CRS cannot magically know about a vulnerability that has just appeared.

But it does not necessarily need to know the name of the vulnerability to recognize the technique used to exploit it. Imagine that a new vulnerability is discovered in a WordPress plugin.

No one has added a rule specifically for that plugin yet.

But if exploiting the vulnerability involves sending a classic SQL injection in a parameter, CRS already knows many patterns characteristic of SQL injections.

It can therefore block the attempt because it recognizes the attack family, not because it knows that specific vulnerability.

new vulnerability
        ↓
exploitation technique
        ↓
SQL injection
        ↓
SQL rules already present in CRS
        ↓
detection

This is also the principle behind what OWASP calls virtual patching: an intermediate security layer can prevent certain exploitation attempts before the vulnerable code is fixed. This obviously does not replace an update.

As soon as a proper fix exists, the vulnerability must be corrected at its source.

The WAF can still temporarily reduce exposure and, more generally, reduce the attack surface.

What about attacks that CRS cannot see?

This is where the OWASP Top 10 also helps explain the limits of a WAF.

Imagine a site where /invoice?id=100 displays your invoice.

If you simply replace 100 with 101 and the application gives you another customer’s invoice, there is an access-control problem. Yet your HTTP request may look perfectly normal.

No suspicious SQL. No JavaScript. No system command. The problem is in the application logic. A generic set of rules cannot know that the logged-in user is not allowed to view that resource.

The same applies to poor authentication architecture, a cryptographic error and other purely logical flaws.

ModSecurity and CRS must be part of a broader setup

A WAF is one layer of protection, not the only one. In my case, ModSecurity and CRS work alongside other protections placed at different points in the infrastructure.

Cloudflare can filter some traffic before it reaches the server. A firewall can restrict certain network access. A tool such as CrowdSec can analyze logs to detect certain events and behaviors recorded in ModSecurity logs.

But that is another subject, and none of these layers makes the others unnecessary.

ModSecurity and CRS analyze web transactions according to rules and intervene when those transactions sufficiently match behaviors considered dangerous.