How to whitelist an IP address in ModSecurity (cPanel and Plesk)

Key takeaways

• Whitelisting an IP in ModSecurity tells the web application firewall to skip rule checks for requests from that address.
• The best whitelisting method depends on your control panel, operating system, and whether the IP address is static.
• URI-based whitelisting is often safer than IP whitelisting, especially when IP addresses change.

What is ModSecurity and why does it block legitimate requests?

ModSecurity is a toolkit for real-time web application monitoring, logging, and access control. In practical terms, ModSec (also called mod_security) is a web application firewall that actively monitors HTTP traffic and blocks web requests that match known attack patterns. 

With nearly 70% of server attacks targeting the application layer, application-level firewalls have become a fundamental component of modern defense-in-depth approaches to server security.

The problem is that ModSecurity’s rules are not perfectly calibrated for every application environment. Since web application firewalls prioritize broad attack detection over application-specific behavior, their rules are specifically designed to identify suspicious patterns more aggressively. And while this approach maximizes security coverage, it can also result in false positives, causing legitimate requests to be blocked.

Editing code inside a content management system, running a developer’s IP through a staging site, or working inside a plugin can all trip a ModSecurity rule, even when nothing malicious is happening. 

When this occurs, ModSecurity blocks the request and may subsequently block the originating IP address if more actions match suspicious patterns. This blocks access to the application or website and stops you or your developer’s work until you resolve it. The fix is called whitelisting: telling ModSecurity to allow requests from a specific IP address or URI, skipping the usual rule checks.

Before whitelisting an IP or a request in ModSecurity, it is important to identify the exact patterns that triggered the block. This ensures that exceptions you apply are based on precise rule matches rather than assumptions, reducing the risk of weakening overall server security. 

You will need three pieces of information from your web server (typically Apache) error log – the IP address the request originated from, the specific URI the request involved, and the ModSecurity rule ID or IDs that were triggered. The steps below walk through how to find them.

How to find the ModSecurity error before you whitelist

Follow the steps below to gather the required information. These steps apply regardless of your control panel.

1.  Find your IP or ask your developer for theirs. You can find your public IP by visiting ip.liquidweb.com.
2. Locate the appropriate web server error log file. On Linux cPanel servers running Apache, it is typically found at /var/log/apache2/error_log, while on Linux Plesk servers it is usually located at /var/log/httpd/error_log. On Windows-based Plesk servers, you can find ModSec error logs at Windows Event Logs > Application > Source = ModSecurity.
3. Search the error log for ModSecurity errors to identify the specific rules that were triggered, as well as the associated URIs. Modify the command with your IP in place of “IP here.” Make sure to provide the correct path to the error log.

4. The output gives you a list of ModSecurity hits from that IP. address You only need three things from it:

• Client IP (the IP address that the request was received from)
• Rule ID (the ID number of the tripped rule or rules within ModSec)
• URI (the specific page or file where the error originated)

Here is an example of what that output looks like:

In the example above, we can find the following information:

• Client IP: [client 61.14.210.4]
• Rule ID: [id “20000221”]
• URI: [uri “/db/index.php”]

Before you proceed, verify that the blocked request was legitimate. Confirm that you or someone in your organization actually made it. It is not unusual for a request to trigger multiple ModSecurity rules at the same time, so make sure you review all appropriate log entries associated with the specific request.

Please note that certain ModSecurity rules function as counters, tracking repeated suspicious activity from a specific IP address. If a defined threshold is reached within a time window specified by the rule, the IP may be blocked or rate-limited. These types of rules are generally not whitelisted. If you are unsure whether a rule can be safely whitelisted, contact a system administrator for assistance.

Methods to whitelist an IP in ModSecurity

Specific methods of whitelisting an IP or ModSec rule depend on your server’s operating system, control panel, and whether you are targeting an IP address or a specific URI. The table below summarizes your options.

Whitelisting an IP address or whitelisting specific rules for a URI in ModSecurity via a configuration file are preferred methods for website owners with root access to the server and basic command-line proficiency. Methods involving a graphical user interface are good for beginners to server administration.

Option 1: whitelisting by IP in ModSecurity via a configuration file on cPanel

Please note that whitelisting an IP in ModSecurity effectively disables all security rule evaluation for requests originating from that address. This creates a significant security risk, as any malicious activity from the whitelisted IP will bypass detection and blocking entirely. If the IP is later misused or assigned to an untrusted user, the application firewall will not intervene, leaving your website fully exposed to attacks from that source.

1. Create a file containing a list of IP addresses that you need to whitelist

Even if you are going to whitelist a single IP address, it is best to put it in a file.

2. Create a new Apache configuration file for whitelisting an IP address

3. Load the newly added configuration file into Apache configuration

4. Whitelist an IP in ModSecurity via ip_whitelist.conf

Add the following rule to ip_whitelist.conf. The id: number must be unique. Do not reuse the ID from the existing error. Assign a new one that does not already exist in your configuration.

5. Check Apache syntax and restart the web server

Test the syntax of the whitelist rules you applied and the rest of the apache configuration before restarting the web server. Make sure the first command returns Syntax OK, otherwise work on correcting the syntax errors reported first.

Option 2: whitelisting by URI in ModSecurity via a configuration file on a per-vhost basis on cPanel

Whitelisting specific ModSecurity rules for a URI via a configuration, we will be following a per-vhost approach. It is preferred because it isolates ModSecurity configurations to individual websites, preventing changes from affecting other hosted applications on the same server. This improves security and control by allowing specific rule exceptions and policies based on the requirements of each website.

1. Create a backup of the main Apache config file

We will be rebuilding Apache configuration, so it will be useful if the changes we apply need to be reverted.

2. Determine the location of vhost include files

Modify the command with your domain name in place of “Domain”. The output will contain two lines that are commented out. One is for the SSL vhost (HTTPS), and one is for the non-ssl vhost (HTTP). You can add an exclusion for HTTPS only or whitelist a rule in both locations so it will work on both HTTP and HTTPS.

3.  Create the referenced directories

Create the appropriate directories by using the mkdir command referencing the path or paths from the above egrep command. The -p flag tells mkdir to create this full path if it doesn’t exist. 

4. Navigate to the newly created directories and create a new file called “modsecexclude.conf”

5. Add the whitelist rules

Add a whitelist, following the example below, where “path/to/uri” is the URI you extracted from the Apache error log, rule_id is the ID of the rule that was triggered. Please note that you can specify multiple rule IDs by listing them in a sequence. 

6. Rebuild Apache configuration

Rebuild the main Apache configuration file to assure the newly created includes directories are uncommented and the modsecexclude.conf files are loaded by Apache.

7. Check Apache syntax and restart the web server

Test the syntax of the whitelist rules you applied and the rest of the apache configuration before restarting the web server. Make sure the first command returns Syntax OK, otherwise work on correcting the syntax errors reported first.

Option 3: whitelisting by rule ID via WHM / ConfigServer ModSecurity Control (CMC)

ConfigServer ModSecurity Control (CMC) plugin for cPanel provides a convenient web-based interface for managing ModSecurity rules and configuration directly from the WHM panel. Available as a free, open source add-on, it simplifies ModSecurity administration by eliminating the need for editing any configuration files manually.

1. Install ConfigServer ModSec Control

Install ConfigServer ModSecurity Control plugin from the official GitHub repository.

2. Whitelist ModSecurity rules and apply the changes

You can use ConfigServer ModSecurity Control to whitelist specific ModSec rules globally, per cPanel or domain basis, or whitelist rules for a specific URI. WHM will save the changes and Apache will restart automatically to apply the new configuration.

Option 4: whitelisting by IP in ModSecurity via a configuration file on Plesk

Whitelisting an IP address in ModSecurity effectively bypasses security rule evaluation for requests originating from that address. If the IP is later reassigned or otherwise misused, ModSecurity will no longer inspect traffic originating from it, potentially exposing the server to attacks from what used to be a trusted source.

1. Create a file containing a list of IP addresses that you need to whitelist

It is best to put the IP addresses you wish to whitelist into a file, even if it will contain a single entry.

2. Whitelist an IP via a ModSecurity configuration file

Add the following rule to /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf. The id: number must be unique. Do not reuse the ID from the existing error. Assign a new one that does not already exist in your configuration.

3. Check Apache syntax and restart the web server

Test the syntax of the newly added whitelist rule and the rest of the Apache configuration before restarting the web server. Make sure the first command returns Syntax OK, otherwise work on correcting the syntax errors reported before giving Apache a restart.

Option 5:  whitelisting by URI via a configuration file on a per-vhost basis on Plesk

When whitelisting specific ModSecurity rules for a URI through a configuration file, a per-virtual host (per-vhost) approach is recommended. This method isolates ModSecurity customizations to individual websites, ensuring that rule exceptions do not affect other applications hosted on the same server.

1. Determine the location of vhost files

Depending on the version of Plesk your server is using, vhost files may be found at the locations below. Make sure to replace “domain” with the domain name of your website.

If the vhost.conf file for a specific domain name exists, append to it. If it does not – create it first.

2. Add the whitelist rules

Add a whitelist, following the example below, where “path/to/uri” is the URI you got from the ModSecurity error, rule_id is the ID of the rule that was triggered. Please note that you can specify multiple rule IDs by listing them in a sequence. 

3. Rebuild the vhost configuration

To apply the newly added expectations, run one of the following commands depending on the version of Plesk you are using. If the server is running Plesk 9.5 or earlier, choose the first command, for Plesk 10 or later, opt for the second command below. Make sure to replace “domain” with the actual domain name of your website.

4. Check Apache syntax and restart the web server

Test the syntax of the whitelist rules you applied and the rest of the apache configuration before restarting the web server. Make sure the first command returns Syntax OK, otherwise work on correcting the syntax errors reported first.

Option 6: whitelist a rule via Plesk web interface

Plesk provides a graphical interface for managing ModSecurity at both the server and domain levels. Server-wide settings can be accessed through Tools & Settings > Web Application Firewall (ModSecurity), domain-specific settings are available under Domains > Select Domain > Web Application Firewall. This flexibility allows you to apply modifications to ModSecurity globally or tailor them to individual websites.

Here are the main ways to modify ModSecurity configurations via Plesk control panel:

Mode

The Mode setting determines how ModSecurity handles requests.

• Off – Disables ModSecurity entirely.
• Detection Only – Logs requests that match security rules without blocking them.
• On – Logs and actively blocks requests that trigger ModSecurity rules.

Disabling Security Rules

You can whitelist a ModSecurity rule using the Switch off security rules interface.

Rule Set Selection

Plesk supports multiple ModSecurity rule sets, with OWASP Core Rule Set (CRS) being generally the preferred choice. It is widely adopted, actively maintained, and well documented, providing active protection against a broad range of web application attacks.

Security Level Profiles

Plesk includes several predefined security profiles. While each profile serves a specific purpose, the Tradeoff profile typically offers the best balance between security and minimizing false positives.

Custom Directives

The Custom Directives section allows you to define additional ModSecurity directives. If you have a server with Liquid Web, this is where custom Liquid Web configuration for ModSecurity can be found.

Important considerations before you whitelist

Getting the syntax right is only part of the job. These considerations apply regardless of which method you use.

• Load balancer environments. If your server is behind a load balancer or proxy such as Cloudflare, REMOTE_ADDR will reflect the proxy’s IP address rather than the original client IP. You can use Apache’s mod_remoteip module to replace REMOTE_ADDR with the actual client address extracted from trusted headers such as X-Forwarded-For in log files.
• Use unique rule IDs when whitelisting an IP address. Every SecRule directive requires a unique id: value. Reusing an ID that already exists in your configuration will cause a conflict and may prevent Apache from starting cleanly.
• Target specific rules, not the entire engine. Where possible, whitelist only the ruler rules that triggered the block, rather than disabling all ModSecurity checks for a specific website. The more targeted the exemption, the smaller the exposure.
• Static IPs only. IP whitelisting is only reliable with a static IP. When an IP changes regularly, old addresses can eventually be reused by someone outside your organization who then inherits the whitelist access. If you cannot guarantee a static IP, use the URI method instead.
• Trusted people only. Anyone whose IP is whitelisted has a path around ModSecurity entirely. If a trusted person’s access changes — a former employee, a contractor whose project ended — remove their IP from the whitelist immediately. Review your whitelist any time team access changes.
• Clean up when you are done. Once the work requiring the whitelist is complete, remove the entry from the configuration file. Permanent whitelists that outlive their original purpose expand your attack surface without adding any value.
• Scope it correctly. The goal is not maximum protection or maximum access. It is managing risk: finding the level of rules that protects the server while still letting you get your work done. Whitelist the minimum required and no more.

Whitelisting in ModSecurity FAQs

Next steps for whitelisting in ModSecurity

ModSecurity is a genuinely useful layer of protection, and whitelisting is a normal part of working with it. The key is keeping your exemptions targeted, temporary where possible, and tied to IPs and rules you have verified. Your business depends on this. It has to work.

If you are not sure which method fits your setup, start with your control panel’s GUI option, cPanel ModSec Manager or the Plesk Custom directives field, to confirm the whitelist works, then move the rule into the appropriate config file for long-term management. Keep a note of every whitelist entry you add so you can review and clean them up over time.

If you manage your own server, keep whitelist entries documented and review them regularly so old exceptions do not become long-term security gaps. For fully managed Liquid Web customers, the Heroic Support team can help review ModSecurity blocks and apply the right exception for your environment.