What Is ModSecurity? WAF Basics and How to Fix 403 Errors

What is ModSecurity and what does it do?

ModSecurity is an open source web application firewall (WAF) engine that attaches to your web server and checks incoming HTTP requests against a set of rules. It can log a suspicious request or stop it with a 403 before it reaches your site. As a result, common attacks such as SQL injection attempts never touch your application.

We are a digital marketing and web team, not a hosting company. Also, everything technical in this guide rests on official documentation. Our goal is simple: when you meet a surprise 403 error one day, you should understand what you are looking at.

On WordPress and e-commerce sites in particular, ModSecurity can be the quiet culprit behind "the site works but my form will not save." Below we explain the concept, how it decides, how to handle false positives, and when to hand the problem to your hosting provider.

So, what is ModSecurity in practice? Picture the path of a request. A visitor asks for a page, the request reaches your web server first, and ModSecurity runs its rules. Only if the request passes does it reach your application, such as WordPress. In short, the WAF is a gate in front of the app, and the app never sees the decision.

What does a web application firewall actually do?

A WAF looks at the content of HTTP traffic, unlike a classic network firewall. Network firewalls decide which IP address may connect to which port. A WAF reads the address, parameters, headers and body of a request and asks one question: does this look like a normal visitor?

That difference matters because most attacks arrive through port 80 or 443, a door that looks completely legitimate. However, closing a port does not protect that door. A WAF filters what walks through it. Also, when you update the rule set, you can gain protection against a new class of attack without touching your application code.

A WAF has three basic jobs:

• It compares requests with a rule set and scores the matches.
• It blocks a request that crosses the threshold, or only logs it.
• It writes every decision to an audit log, so you can review it later.

Still, a WAF is not a magic shield. It will not fix a vulnerability inside an outdated plugin. Instead, it only tries to stop the known patterns that people use to exploit such holes.

What is ModSecurity's engine and how does it differ from a rule set?

People use the word "ModSecurity" for two different things, and that causes confusion. The engine is the software that reads rules and applies them to requests. The rule set is the collection of instructions that tells the engine what to look for. In other words, with no rules the engine blocks nothing.

According to the official reference manual, the SecRuleEngine directive controls how the engine behaves, and its default value is off. So installing the engine does not protect you. Instead, you need to load rules and switch the engine on.

In practice you meet three layers:

• Engine: ModSecurity itself, a module that plugs into a web server such as Apache.
• Rule set: usually the OWASP Core Rule Set (CRS), or a commercial set your host chose.
• Custom rules: exceptions and extra rules that your provider or you add.

In practice, knowing which layer you are debugging makes the logs far easier to read. For example, if the engine is off, blaming the rule set makes no sense. If you switched it on and loaded a rule set, you should see a rule ID in the log. If you see none, then the problem may lie elsewhere.

What is ModSecurity compared with a network firewall or IP blocking tools?

Several server security tools look similar, but each works at a different layer. A network firewall looks at the connection, meaning the IP address and port. Log-based IP blocking tools watch repeated failed attempts and keep the address out for a while. ModSecurity looks at the content of a request after the connection exists.

Put simply, these layers do not replace one another. For instance, a network firewall with port 443 open knows nothing about what a request contains. A WAF, on the other hand, cares only about the HTTP content, whatever the port.

In short, you can sum up the layers like this:

• Network firewall: who may connect to which door.
• IP blocking tools: who made too many failed attempts.
• WAF: whether the content of this request looks normal.

Details of the other tools are a separate topic. This guide stays focused on ModSecurity.

What does the OWASP Core Rule Set try to catch?

The OWASP Core Rule Set is a collection of generic attack detection rules for ModSecurity and compatible engines. Its goal is to catch common risk classes, such as those in the OWASP Top 10, without you writing custom rules for your own application.

Specifically, the rule set looks at families of patterns, not single signatures. For example, it covers classes such as:

• SQL injection and command injection attempts.
• Cross-site scripting (XSS) attempts.
• Path traversal and local file read attempts.
• Malformed or protocol-violating HTTP requests.
• User agent signatures of known scanners and attack tools.

Because they add nothing for you, we deliberately do not write attack signatures in this guide. Some server firewalls may even reject a page that contains them. Knowing the category names is enough to understand the decisions. Also remember that the rule set is generic. It does not know how your application really behaves, so it sometimes flags a legitimate request.

How does anomaly scoring decide whether to block?

CRS does not block on the first matching rule. Each matching rule raises the anomaly score of the request according to its severity. If the total reaches the threshold at the end, the engine denies the request. In other words, the CRS documentation calls this method collaborative detection.

The documented defaults look like this:

• Inbound request threshold: 5.
• Outbound response threshold: 4.
• A CRITICAL rule adds 5 points, ERROR 4, WARNING 3 and NOTICE 2.

So a single CRITICAL match crosses the default threshold on its own. Likewise, two lower severity matches can reach it together. The documentation also states the order. Request rules run first, followed by a threshold check. Then response rules run, and a second threshold check follows.

Because of this, when you get a 403 you should ask one question. Did one rule cause the block, or did several small matches add up?

Why do paranoia levels increase false positives?

CRS splits its rules into four paranoia levels (PL), and each level adds rules on top of the previous one. According to the official description, PL 1 is baseline protection with minimal need to tune away false alarms. The second level suits sites that handle real user data. PL 3 offers banking grade security but produces many false alarms. Finally, the fourth level is the strictest.

The documentation also warns that running a high paranoia level in blocking mode without tuning is very risky. It also adds that tuning PL 4 can take many weeks.

In short, protection rises with the level, but so does the number of legitimate requests that get stuck.

Asking your provider which level they use should be one of your first questions when you troubleshoot.

What is ModSecurity's DetectionOnly mode, and how does it differ from blocking mode?

The engine's SecRuleEngine directive takes three values. On processes rules and blocks. Off does not process rules at all. DetectionOnly processes the rules but, in the manual's words, never runs a disruptive action such as block, deny, drop or redirect.

So DetectionOnly is a watch mode. Instead, matches land in the log, and the visitor notices nothing. It is the safest way to start when you bring in a new rule set, because you see which requests would get stuck without cutting any real traffic. Many people who ask what is ModSecurity assume this mode means "protection off." In fact the rules run, and only the verdict stays unenforced.

You can think about the modes roughly like this:

• New setup: start with DetectionOnly and watch the logs.
• Tuning finished: switch to blocking mode (On).
• Troubleshooting: find the responsible rule before you turn the engine off.

A sample configuration line looks like this:

SecRuleEngine DetectionOnly

However, you change this line only if you manage your own server. On shared hosting, that decision belongs to your provider instead.

What is ModSecurity doing when cPanel turns it on?

Many hosting providers include ModSecurity in their cPanel environment as a security layer. According to cPanel documentation, the user interface lets you turn ModSecurity on or off for all domains at once, or set each domain separately. Before you configure individual domains, you must enable it under "Configure All Domains."

The cPanel documentation strongly recommends keeping ModSecurity on for all domains. It also tells you to switch it off only while you investigate ModSecurity related problems. If you cannot see the interface, the documentation says your provider must install the mod_security2 Apache module and enable the ModSecurity Domain Manager feature in WHM.

On the administrator side (WHM), general settings such as the audit log level and the rules engine live in their own screen. Those belong to the provider, and an ordinary hosting customer cannot reach that screen. In practice, this split decides who you ask for what. You can change a per domain switch yourself, but you ask the provider for a rule level exception.

What is a false positive and how do you recognize one?

According to the CRS documentation, when a legitimate transaction makes a rule match by mistake, that is a false positive. However, the fix is not to delete the rule. The fix is to write a rule exclusion for that specific case.

You can recognize a false positive from these signs:

• A 403 Forbidden error appears when you submit one particular form.
• The same page works in another browser or with different content.
• Saving a setting in the admin panel returns a blank page or an error.
• The problem appears only for one action, such as saving a long product description.

Note also that a 403 does not come only from ModSecurity. File permissions, .htaccess rules or another security plugin can also produce one. So you need to confirm the source of the error first.

In practice, a simple pre-test helps. Try the same action from a different network, for example your phone on mobile data. If the result does not change, the problem most likely sits on the server side, not in your own network.

How do you read a false positive from the log?

The log is the only reliable way to solve the problem. According to the official reference, when you set SecAuditEngine to RelevantOnly, the engine records only transactions that raised a warning or an error, or that it considers relevant. However, the default value is off. The SecAuditLogParts directive chooses which parts the record contains, and its default is ABCFHZ.

These are the details you look for in a record:

1. ID of the rule that fired.
2. Message and tags of the rule.
3. Part of the request that triggered the match, such as a parameter or a header.
4. Time and address of the request.

Above all, the rule ID is the only key you need to write an exception. Without it, getting help from your hosting provider also gets harder. So always include the timestamp and the address in a support ticket.

The location of the log file differs by provider. On shared hosting, for example, you may not have access to the file. In that case, ask your provider for the relevant log line instead.

Can an audit log contain personal data, and how do you protect it?

It can. According to the part letters in the official manual, an audit record may contain request headers and the request body. A request body can hold names, email addresses and similar fields from a form. So the record you open while hunting a false positive may show your visitors' data.

For that reason we suggest these habits:

• Share records only with the people who will solve the problem.
• Black out personal fields when you attach a log line to a ticket.
• Ask your provider how long they keep the records.
• Do not log every transaction without need. The cPanel documentation also warns against logging all transactions.

If you have personal data obligations, clarify this topic with your legal adviser as well. That said, we do not give legal opinions here. Instead, we only remind you that a record can carry this kind of data.

How do you write a rule exclusion?

There are two ways to write an exception. The CRS documentation separates them into configure-time and runtime exclusions. First, at configure time, SecRuleRemoveById removes a rule from the start. Second, at runtime, ctl:ruleRemoveById applies only to a specific request.

According to the official manual, the SecRuleRemoveById directive must come after the rule it disables. Runtime exclusions work the opposite way and must sit before CRS loads, because changing a rule after it has run has no effect. In addition, the ctl action does not support regular expressions.

Note first that the sample below is for illustration only. The number 920230 is a rule ID that the CRS documentation uses as an example. However, the number in your own log will differ.

SecRule REQUEST_URI "@beginsWith /example-form/" "id:1000001,phase:1,pass,nolog,ctl:ruleRemoveById=920230"

This exception switches off one rule on the /example-form/ address only. Therefore, that is far safer than disabling the whole rule set.

Why is turning ModSecurity off completely a bad idea?

It looks like a quick fix, but it costs a lot. In practice, the moment you switch it off, every request to your site goes unchecked. Worse, you never learn the real cause, so the problem returns somewhere else next time.

We suggest this order instead:

1. Reproduce the 403 and note the time.
2. Find the ID of the triggering rule in the log.
3. Ask for, or write, a narrow exception for that address or parameter.
4. Repeat the action after the exception and verify the log.

The cPanel documentation points the same way. In short, turn ModSecurity off only while you troubleshoot. If you did turn it off, switch it back on as soon as you finish.

The only sensible use of switching it off is a short test to learn whether ModSecurity really causes the problem. Then, when the test ends, protection should return. Also, set the length of the test in advance and make no other change during it. Otherwise you cannot tell what fixed the problem.

Why does WordPress throw 403 errors?

WordPress sends requests that ModSecurity knows well, yet they often get stuck. For example, the admin panel, plugins and page builders send many detailed requests. Some of them carry long parameters or formatted content.

For example, content you save with a page builder sends layout data and HTML fragments in one request. As a result, the rule set may find that body suspicious. Likewise, the background requests of the admin panel, such as admin-ajax, are among the addresses that often get stuck.

These situations get stuck most often:

• Saving a product description with long content or HTML.
• Submitting multi-field forms on plugin settings pages.
• Uploading a large file while you install a theme or plugin.
• Typing special characters into a search box.

The fix stays the same: find the rule ID and ask for a narrow exception. Our guide on WordPress versus custom code also shows why plugin dependence raises the maintenance load.

Why do payment callbacks and notifications get stuck on e-commerce sites?

The most expensive false positive in e-commerce is a blocked notification from your payment provider, such as a webhook or a return address. The customer pays, but the order stays "unpaid."

These requests do not come from a human browser. Instead, they come from another server, often with unusual headers and a signed body. If the rule set treats them as automated tool traffic, it may return a 403.

The signs look like this:

• Orders stay "pending" even though payment went through.
• Your payment provider's dashboard shows a notification error.
• Failures appear only on the post-payment address.

The fix is a narrow exception based on the rule ID for that notification address. However, leaving the whole site unprotected is not a fix. Also, always verify the notification address against the payment provider's own documentation. For the link between page speed and conversion, see our article on whether page speed affects e-commerce sales.

What should you do when a form returns 403? A worked example

The scenario below is purely an example, not a real client case. Say you submit your contact form and a "403 Forbidden" page appears, while the rest of the site works fine.

First, try the form with a short message. If the short text passes and the long one gets stuck, the content itself may trigger the rule. Next, send the same form from a different network. If nothing changes, then the problem is not in your network.

Then follow these steps:

1. Note the time of the error as precisely as you can.
2. Write down which address and which method you used.
3. If you can reach the log, find the rule ID. If not, ask your provider.
4. Request a narrow exception, then retry the form.
5. Check that other pages are not affected.

In practice, following this order gives you a faster and safer result than a broad request such as "turn ModSecurity off."

What information should you send your hosting provider?

A well prepared support ticket turns days into minutes. The provider's job gets easier because they can find the relevant record directly.

Add these to your ticket:

• The full address (URL) of the error and the method you used, such as opening a page or submitting a form.
• The date and time of the error, with the time zone.
• Your own IP address; you can find it with our IP lookup tool.
• A screenshot and the full text of the error message.
• The date the problem started and what you changed before then.

Also write this: "I would like to know which ModSecurity rule this request triggered, and whether you can add a narrow exception for this address." That tells the provider you expect a correct setting, not a shutdown. Sending the ticket in writing helps too, because you can check later what changed.

Who manages ModSecurity on shared hosting, a VPS and managed plans?

Responsibility depends on the type of hosting. The table below shows the general trend. However, the exact situation depends on your provider's terms.

Also, it helps to ask this question when you pick a host. We cover the topic in our guide on how to choose web hosting. There you can see that WAF support is also a comparison criterion.

The general rule is this: instead of tinkering with a layer you do not manage, contact your provider with clear information. On a VPS without a panel, however, the whole job falls on you. In that case, take a backup before any change and test it first.

How do you set up ModSecurity safely on your own VPS?

If you manage your own VPS, the order you follow is clear. We do not give individual commands here, because package names and file paths differ by distribution. Instead, always verify commands in your distribution's official documentation and on the CRS installation page.

The safe order is:

1. Install the ModSecurity engine from your distribution's official package.
2. Get the CRS rule set from the official source and include it as its documentation describes.
3. Leave SecRuleEngine on DetectionOnly at first.
4. Switch on the audit log and watch real traffic.
5. Write narrow exceptions for the false positives you find.
6. Once the logs calm down, move to blocking mode and keep watching.

Skipping this order and starting straight in blocking mode may mean your customers see a 403 within the first hour. Trying the change on a small copy before the live site is also a good habit. Also, before any change, review your backup strategy as well.

Is a WAF enough on its own, and how does it relate to the OWASP Top 10?

No, it is not enough. A WAF is one layer of defense and does not replace the security of the application itself. In other words, an application written securely resists vulnerabilities better, even without a WAF.

The risks in our OWASP Top 10 guide usually have their roots in code and configuration. A WAF makes exploiting those risks harder, but it does not repair the source.

Think of your security layers like this:

• Up to date software, plugins and themes.
• Strong passwords and two-step verification.
• A correctly configured SSL certificate and HTTPS.
• Regular backups.
• ModSecurity as the WAF.

In practice, each of these works against a different risk. However, more of one layer never makes up for the lack of another. For example, a very strict WAF cannot fully close the hole in an outdated plugin.

Does ModSecurity affect site speed and SEO?

Comparing every request with rules means processing load. Specifically, the size of the effect depends on the rule set, the paranoia level and the server resources. That said, we have no universal figure, and we do not quote numbers without a source. If you suspect a noticeable slowdown on your site, measure first.

However, the real SEO risk sits elsewhere. If a search engine bot visits a legitimate page and gets a 403, then it cannot crawl that page. So false positives can affect crawlability, not just forms.

You can take these precautions:

• Check that your key pages open from a different device and a different network.
• Retest critical pages after a new plugin or a rule change.
• Keep your crawl rules under control with a robots.txt generator.

For the wider performance picture, our article on how site speed affects SEO is a good start.

When should you leave it to your provider instead of doing it yourself?

The honest answer is that most website owners should never touch ModSecurity. Above all, what matters is describing the problem well and sending it to the right person. A good description says when, where and during which action you saw the error.

Leave the job to your provider in these cases:

• You use shared hosting and cannot reach the rule files.
• No rule ID turns up in the log.
• Your change would touch the payment flow on a live e-commerce site.
• No backup exists, or your rollback plan is unclear.
• Server management is new to you.

On the other hand, you can go ahead yourself if you manage your own VPS, have a test environment and can read the logs. Even then, make changes in small steps.

If you want to think through security, speed and infrastructure decisions together, our web design service covers these topics as well. For the domain and DNS side, a DNS lookup tool also helps.

What should your next steps be after learning what is ModSecurity?

In short, ModSecurity is a filter that sits in front of your site and scores requests. In short, when you configure it correctly, it works quietly. However, when a false positive appears, you fix it by tuning, not by switching it off.

Your practical checklist:

1. Confirm that ModSecurity really causes the problem.
2. Find the rule ID and the time in the log.
3. Ask for, or write, a narrow exception.
4. Retest to verify the result.
5. Note the change and recheck your important pages.

Your visibility and conversions are our business. If you want to look at how technical infrastructure affects search results, see our SEO consulting and e-commerce consulting pages.

Sources: CRS anomaly scoring, CRS paranoia levels, CRS false positives and tuning, ModSecurity configuration directives, cPanel ModSecurity documentation, WHM ModSecurity settings.