Skip to main content
Submit a request

Understanding ModSecurity (and false positives)

Maxim Tsitsejev
Updated

Applies to: All plans.

ModSecurity is a web application firewall (WAF) that runs on every Maxinodes server, using the OWASP Core Rule Set. It inspects incoming web requests and blocks ones that look malicious — SQL injection, cross-site scripting, path traversal, suspicious uploads, automated attacks and similar. It is the front door of our security stack, alongside server-side malware scanning and CloudLinux account isolation.

Most of the time you never notice it. Occasionally, though, a perfectly legitimate action — saving a long page in your CMS, uploading a file, submitting a form — matches a security rule and gets blocked anyway. That is called a false positive, and it is quick for us to fix.

Symptoms

You may have hit a ModSecurity false positive if:

  • A specific action returns a 403 Forbidden or an "Access Denied" / "Not Acceptable" page, while the rest of the site loads fine.
  • The block is reproducible — the same button, form or upload fails every time.
  • It started right after you saved certain content (a post with code in it, a complex form, a plugin update).
  • Only one page or one action is affected, not the whole site.

If your whole site is down or throwing a 500, that is a different problem — see My website is down or showing a 500 error.

Common causes (most likely first)

  1. Content that looks like an attack. Code snippets, SQL-like text, URLs or special characters in a post, comment or form field can trip a rule even when they are harmless.
  2. File uploads. Certain file types, large uploads or unusual filenames can match an upload-filtering rule.
  3. Plugins, themes or apps with unusual requests. Some page builders, security plugins or import/export tools send requests that resemble attack patterns.
  4. A genuine attack being blocked. Sometimes the firewall is doing exactly its job — repeated probing of your login or admin URLs.

Quick fixes you can try

  1. Confirm it is reproducible. Repeat the exact action and note what you clicked. A one-off 403 may just have been a passing block.
  2. Note the exact time and your IP address. We match the block in the server logs by timestamp and source IP, so this speeds things up a lot.
  3. Test from a different network if you can. This helps us tell a false positive apart from an IP that has been temporarily blocked.
  4. Check it is not a different limit. If you see a 508 "Resource Limit Reached" page instead of a 403, that is CloudLinux, not ModSecurity — see Resource limit reached and 508 errors explained.

Important: Please do not disable site security yourself or try to "work around" the firewall by changing rules. Whitelisting the specific rule is safer than turning protection off — and it is a job for us.

If that did not work: ask support to whitelist the rule

ModSecurity rules are tuned at the server level, so the fix is for our team to whitelist the specific rule for your action. We can do that without weakening your site's protection.

Start a chat or open a ticket and include:

  • Your domain and the exact URL or page where it happens.
  • The action that triggers it (for example "saving a post in WordPress", "uploading a PDF on the contact form").
  • The exact error text you see on screen.
  • The date, time and your public IP address when it last happened — you can find your public IP with any "what is my IP" search.
  • A screenshot if you have one.

Result: We locate the blocked request in the logs, confirm it is a false positive, and add a targeted whitelist (a rule exclusion) so your legitimate action goes through while real threats stay blocked.

On Managed plans we monitor and tune this for you and can act faster. On Self-Managed, our chat and email support will still whitelist confirmed false positives — see What our support covers.

Related articles

Comments

0 comments

Please sign in to leave a comment.