> ## Documentation Index
> Fetch the complete documentation index at: https://help.noxity.io/llms.txt
> Use this file to discover all available pages before exploring further.

# ModSecurity

> The web application firewall on every Noxity hosting account. Toggle protection per domain, see which rules fired, exempt a rule when it false-positives a real request.

ModSecurity is the open-source web application firewall that sits in front of every site on Noxity hosting. It inspects every HTTP request against a rule set (we use the OWASP Core Rule Set) and blocks requests that match attack patterns: SQL injection, cross-site scripting, path traversal, common exploit fingerprints, etc.

The cPanel ModSecurity tool lets you turn it on and off per domain, browse the rules, and exempt rules that false-positive on traffic you actually want.

Open it from cPanel home → **Security** → **ModSecurity**.

<Frame caption="ModSecurity domain list with per-domain toggle">
  <img src="https://mintlify.s3.us-west-1.amazonaws.com/noxity/images/cpanel/security-settings/modsecurity/listing-light.png" alt="ModSecurity page with toggle per domain" className="block dark:hidden" />

  <img src="https://mintlify.s3.us-west-1.amazonaws.com/noxity/images/cpanel/security-settings/modsecurity/listing-dark.png" alt="ModSecurity page with toggle per domain" className="hidden dark:block" />
</Frame>

## Per-domain toggle

The first tab lists every domain on the account with a switch:

* **On.** ModSecurity inspects requests to this domain. This is the default and the recommended state.
* **Off.** Requests pass through without inspection.

Turn it off only when a rule is breaking real functionality and you can't isolate which one. Even then, prefer to exempt the specific rule rather than disable the firewall on the whole domain.

## See which rules fire

The **Hit List** tab shows recent requests that ModSecurity blocked or flagged. Each row has:

* **Timestamp.** When the request hit the rule.
* **Rule ID.** The rule that fired (e.g. `949110` is the OWASP "anomaly score exceeded" rule).
* **IP address.** Where the request came from.
* **Host.** Which of your domains was the target.
* **URI.** The path the attacker tried to hit.
* **Action.** What ModSecurity did (`deny`, `log`, `pass`).

Click a row to see the full request body and the rule definition. Useful for two things: confirming the firewall is doing its job, and diagnosing false positives.

## Exempt a rule

If a real visitor or your own legitimate WordPress plugin is tripping a rule, exempt the rule rather than disabling ModSecurity wholesale.

<Steps>
  <Step title="Find the Rule ID in the Hit List">
    Reproduce the failure, refresh the Hit List, copy the Rule ID of the row that matches.
  </Step>

  <Step title="Open the Hit List entry">
    Click the row. cPanel shows full context: the request body, the matched pattern, and a **Disable Rule** button.
  </Step>

  <Step title="Disable the rule">
    Click **Disable Rule**. cPanel writes an exemption that disables the rule for your account. The action is immediate, no restart needed.

    For per-domain or per-path exemptions (rather than account-wide), open a ticket; we'll write a more targeted `SecRuleRemoveById` directive into your VirtualHost.
  </Step>
</Steps>

## Common rule classes

| Rule range     | What it catches                                     |
| -------------- | --------------------------------------------------- |
| 941xxx         | Cross-site scripting (XSS) attempts                 |
| 942xxx         | SQL injection                                       |
| 943xxx         | Session fixation                                    |
| 944xxx         | Java / Apache Struts exploits                       |
| 949xxx         | Anomaly score thresholds (the "summary" rules)      |
| 980xxx         | OWASP CRS internal correlation rules                |
| 218xxx, 219xxx | Bot detection and rate limiting (vendor extensions) |

A request can match several rules; the anomaly score adds them up and trips a single 949xxx block once it crosses the threshold.

## Common issues

<AccordionGroup>
  <Accordion title="Legitimate forms post empty fields and get blocked">
    Some 942xxx SQL injection rules are aggressive about quote characters and SQL keywords. A user typing **don't** in a contact form can match. The fix is a per-rule exemption (Disable Rule on the specific rule ID), not turning the firewall off.
  </Accordion>

  <Accordion title="My WAF won't let me upload a file">
    File upload often triggers 941 (XSS) on filenames containing characters like `<`, `>`, `;`. Rename the file before uploading, or exempt the upload endpoint via a ticket.
  </Accordion>

  <Accordion title="WordPress admin or page builder breaks after enabling ModSecurity">
    Page builders like Elementor and Divi POST big chunks of HTML and JavaScript that look like XSS to a generic rule. There's a known set of rule IDs to exempt for each major builder; open a ticket with the page builder name and we'll apply the standard exemptions.
  </Accordion>

  <Accordion title="The Hit List is empty even after a clear attack">
    ModSecurity is off on that domain (check the toggle), or the attack didn't match a CRS rule. Layered defense (Imunify360, Cloudflare WAF) catches what the rule set misses.
  </Accordion>
</AccordionGroup>

## Need a hand?

<CardGroup cols={2}>
  <Card title="Open a ticket" icon="life-ring" href="https://members.noxity.io/submitticket.php">
    Best for anything that needs an account check or a config change on our end.
  </Card>

  <Card title="Live chat" icon="messages" href="https://noxity.io/contact">
    Faster for quick questions during business hours.
  </Card>
</CardGroup>