{"id":6185,"date":"2026-08-14T10:14:23","date_gmt":"2026-08-14T07:14:23","guid":{"rendered":"https:\/\/www.scalahosting.com\/kb\/?p=6185"},"modified":"2026-08-14T10:14:24","modified_gmt":"2026-08-14T07:14:24","slug":"modsecurity-per-domain-spanel","status":"publish","type":"post","link":"https:\/\/www.scalahosting.com\/kb\/modsecurity-per-domain-spanel\/","title":{"rendered":"How to Enable or Disable ModSecurity for One Domain in SPanel"},"content":{"rendered":"\n

SPanel lets you turn ModSecurity on or off for a single domain from the domain’s Settings <\/strong>dialog, using the Mod_security ON\/OFF toggle. The setting applies only to the domain you edit, so you can disable the WAF on one site that hits a false positive without touching the others on your account. ModSecurity is ON by default, and disabling it removes a protection layer – so use it to debug a false positive and turn it back on once you have a fix.<\/p>\n\n\n\n

Who this is for<\/strong><\/h2>\n\n\n\n

This is for developers and site owners who run a legitimate request – a form post, a file upload, an API call – and get a 403 error from the web application firewall. You suspect the rule is wrong for this site and want to confirm that before rewriting the request, without weakening the other domains under the same SPanel account.<\/p>\n\n\n\n

What problem this solves<\/strong><\/h2>\n\n\n\n

A ModSecurity rule that fires on bad traffic can also fire on traffic that is fine for your app – think of a page builder, an import tool, or a webhook posting content the WAF reads as an attack. Without a per-domain control you would either live with the block or ask for an account-wide change that exposes every other site. The toggle narrows the blast radius: you change one domain, prove the WAF was the cause, and leave the rest protected.<\/p>\n\n\n\n

How SPanel solves this<\/strong><\/h2>\n\n\n\n

The control lives in each domain’s Settings dialog. In SPanel, go to Domains<\/strong>, find the domain’s row, open the Actions<\/strong> menu, and choose Settings<\/strong>. Inside that dialog is a Mod_security<\/strong> ON\/OFF toggle (the UI spells it Mod_security). It applies to that one domain only, and the default state is ON.<\/p>\n\n\n\n

To change it, flip the toggle and Save<\/strong>. The dialog then reflects the new state, and the change takes effect for incoming requests to that domain – there is no separate restart step. Rule-level tuning – switching off one specific rule rather than the whole engine – is not exposed here and may require admin-level access.<\/p>\n\n\n\n

Why this is different in SPanel<\/strong><\/h2>\n\n\n\n

Two things are worth calling out. First, the toggle is genuinely per-domain: disabling the WAF for one site that trips a false positive leaves every other domain on the account protected, so you are not making an account-wide trade-off to fix one site.<\/p>\n\n\n\n

Second, the toggle sits in the same Settings dialog as the document root and hotlink protection controls, so the per-domain settings you reach for most often are in one place rather than spread across separate screens.<\/p>\n\n\n\n

Before you start<\/strong><\/h2>\n\n\n\n
    \n
  • Access to the SPanel User Interface for the account that owns the domain.<\/li>\n\n\n\n
  • The correct domain in mind – the toggle changes only the domain whose Settings you opened.<\/li>\n\n\n\n
  • An understanding of the trade-off: turning Mod_security OFF removes a protection layer for that domain until you turn it back on.<\/li>\n\n\n\n
  • A plan to re-enable it, ideally a specific request to retest, so the WAF does not stay off longer than the debugging window.<\/li>\n<\/ul>\n\n\n\n

    Step-by-step<\/strong><\/h2>\n\n\n\n
      \n
    1. Open the Actions<\/strong> drop-down menu and select Settings<\/strong>. You should see the per-domain controls, including the Mod_security<\/strong> toggle.<\/li>\n\n\n\n
    2. In SPanel, open Domains<\/strong> and find the row for the domain you want to change, for example yoga.life.<\/li>\n<\/ol>\n\n\n\n
      \"How<\/figure>\n\n\n\n
        \n
      1. Safety check before you disable: confirm this is the right domain and that you intend to remove WAF protection for it. Turning Mod_security OFF leaves the site without the firewall layer until you re-enable it.<\/li>\n\n\n\n
      2. Flip the Mod_security<\/strong> toggle to OFF to disable the WAF, or to ON to re-enable it. The default is ON.<\/li>\n\n\n\n
      3. Click Save<\/strong>. The dialog should now show the toggle in its new position, and the change applies to requests to that domain.<\/li>\n\n\n\n
      4. Retest the blocked request. If it now succeeds with the WAF off, you have confirmed ModSecurity was the cause. Turn the toggle back ON and Save once you have a longer-term fix.<\/li>\n<\/ol>\n\n\n\n

        What happens behind the scenes<\/strong><\/h2>\n\n\n\n

        The toggle enables or disables the ModSecurity engine for that domain’s web server configuration. SPanel applies the change for you, so you do not edit a config file or restart a service by hand. Because the setting is scoped to the single domain, the result is a controlled test: you isolate one variable – the WAF – for one site, with no account-wide side effects.<\/p>\n\n\n\n

        Limitations and edge cases<\/strong><\/h2>\n\n\n\n
          \n
        • Disabling the WAF removes a protection layer.<\/strong> With Mod_security OFF, that domain no longer gets firewall filtering. Only disable it to debug a false positive, then re-enable it as soon as you have a fix.<\/li>\n\n\n\n
        • The control is per-domain, not per-URL or per-rule.<\/strong> You cannot turn the WAF off for a single page or a single rule from this dialog – it is the whole engine for the whole domain. If only one rule is the problem, plan for a narrower fix rather than leaving the engine off.<\/li>\n\n\n\n
        • Individual rule tuning may require admin-level access<\/strong>. Switching off a specific rule is not part of this per-domain toggle, so you may need to escalate to whoever administers the server.<\/li>\n<\/ul>\n\n\n\n

          Troubleshooting<\/strong><\/h2>\n\n\n\n
          Symptom<\/strong><\/td>Likely cause<\/strong><\/td>What to do<\/strong><\/td><\/tr>
          Request still blocked after turning off ModSecurity<\/td>Edited the wrong domain’s Settings<\/td>Reopen Domains, confirm the row, and check the toggle in that domain’s dialog<\/td><\/tr>
          403 returns even with WAF off<\/td>The block is not coming from ModSecurity<\/td>Re-enable the WAF and look at app logs, permissions, or other rules<\/td><\/tr>
          Want to disable just one rule<\/td>Per-domain toggle covers the whole engine<\/td>Ask the server administrator about rule-level tuning<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

          When to use this \/ when not to use this<\/strong><\/h2>\n\n\n\n
          Use this when<\/strong><\/td>Skip or use something else when<\/strong><\/td><\/tr>
          A legitimate request on one site is blocked by the WAF<\/td>You want protection off for every domain at once<\/td><\/tr>
          You need to confirm ModSecurity is the cause of a 403 error<\/td>You only need one specific rule disabled<\/td><\/tr>
          You can re-enable the WAF promptly after testing<\/td>The site handles sensitive data and cannot run unprotected<\/td><\/tr>
          You want to isolate one domain without touching others<\/td>The block is clearly an app bug, not the WAF<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

          FAQ<\/strong><\/h2>\n\n\n\n

          Q:<\/strong> Does turning off Mod_security affect my other domains?<\/strong><\/p>\n\n\n\n

          A:<\/strong> No. The toggle is per-domain and changes only the domain whose Settings you opened. Other domains remain protected.<\/p>\n\n\n\n

          Q:<\/strong> Is ModSecurity on or off by default?<\/strong><\/p>\n\n\n\n

          A:<\/strong> It is ON by default. You have to open the Settings dialog and change the toggle to disable it.<\/p>\n\n\n\n

          Q:<\/strong> Can I disable the WAF for just one page or URL?<\/strong><\/p>\n\n\n\n

          A:<\/strong> No. This control is per-domain, not per-URL or per-rule – it enables or disables the engine for the whole domain.<\/p>\n\n\n\n

          Q:<\/strong> How do I turn protection back on?<\/strong><\/p>\n\n\n\n

          A:<\/strong> Open the same domain’s Settings dialog, flip the Mod_security toggle to ON, and click Save. Re-enable it as soon as your debugging is done.<\/p>\n\n\n\n

          Q:<\/strong> Can I turn off a single ModSecurity rule instead of the whole engine?<\/strong><\/p>\n\n\n\n

          A:<\/strong> Rule-level tuning may require admin-level access; ask the server administrator.<\/p>\n\n\n\n

          Q:<\/strong> My request is still blocked after disabling the WAF. Now what?<\/strong><\/p>\n\n\n\n

          A:<\/strong> Confirm you edited the correct domain. If the block persists, the cause is likely elsewhere – re-enable the WAF and check your application logs and permissions.<\/p>\n\n\n\n