This article explains how ModSecurity WAF works, what types of attacks it blocks, and what to do if a legitimate request is being blocked on your HOSTDOG hosting account. ModSecurity is included free with every hosting plan and requires no setup on your part.
What is a web application firewall
A web application firewall (WAF) sits between the internet and your website, inspecting every incoming HTTP request. It analyses the request's URL, headers, body, and parameters against a set of security rules. Requests that match known attack patterns are blocked before they reach your application code.
Think of it as a security checkpoint: legitimate traffic passes through normally, while malicious requests — SQL injections, cross-site scripting attempts, file inclusion attacks — are stopped at the gate.
How ModSecurity works on HOSTDOG servers
ModSecurity is an open-source WAF module integrated directly into the web server on all HOSTDOG hosting plans. It uses the OWASP Core Rule Set (CRS) — a widely maintained collection of rules designed to detect and block the most common web attacks.
When a request arrives at your website, ModSecurity:
- Parses the full HTTP request (URL, query strings, POST data, cookies, headers)
- Compares it against hundreds of security rules looking for attack signatures
- Blocks the request and returns a
403 Forbiddenerror if a rule is triggered - Logs the event for review in the server's error log
This entire process happens in milliseconds and is transparent to your visitors. Legitimate traffic is never affected.
What ModSecurity protects against
ModSecurity guards against the most common and dangerous web application attacks, including:
| Attack type | What it does |
|---|---|
| SQL injection (SQLi) | Injects malicious database queries through form fields or URLs to steal or manipulate data |
| Cross-site scripting (XSS) | Injects JavaScript into pages to steal cookies, redirect visitors, or deface the site |
| Remote file inclusion (RFI) | Tricks the server into loading and executing a malicious file from an external source |
| Local file inclusion (LFI) | Exploits file paths to read sensitive server files like configuration or password files |
| Brute-force attacks | Rapid automated login attempts to guess passwords for admin panels |
| Protocol violations | Malformed HTTP requests designed to exploit server vulnerabilities |
ModSecurity and Imunify360: how they work together
ModSecurity and Imunify360 operate on different layers but complement each other:
- ModSecurity focuses on HTTP request filtering — it examines what is being sent to your website and blocks malicious payloads based on predefined rulesets.
- Imunify360 adds behavioural analysis, machine learning, real-time malware scanning, intrusion detection, and automated cleanup at the server and file level.
Together, they create a multi-layered defence: ModSecurity stops attacks at the request level, while Imunify360 catches anything that gets past the first layer and also monitors file system activity.
What to do if a legitimate request is blocked
Occasionally, ModSecurity may block a legitimate action — for example, saving a blog post with certain code snippets, submitting a form with unusual characters, or using a plugin that sends requests matching an attack pattern. If this happens:
- You or your visitor will see a
403 Forbiddenerror when trying to perform the action - The block is logged in the server's error log with a rule ID that identifies which specific rule was triggered
To resolve a false positive, contact HOSTDOG support with the details of the action that was blocked (what you were doing, the URL, and the approximate time). Our team can review the error log, identify the triggered rule, and create an exception if appropriate.
Frequently asked questions
No. ModSecurity is pre-configured and active on all HOSTDOG servers with the OWASP Core Rule Set. It works automatically without any setup on your part.
The impact is negligible. ModSecurity processes each request in milliseconds. The security benefit far outweighs the minimal processing overhead, and it is optimised for shared hosting environments.
Disabling ModSecurity entirely is not recommended and not available as a self-service option. If a specific rule is causing false positives, contact our support team. We can create targeted exceptions for specific URLs or rules without reducing your overall protection.