The attacks that target your application
A web application firewall (WAF) reads each HTTP request and stops the ones that try to exploit the software behind your website. Shieldify inspects requests at the edge, so an exploit attempt is blocked before it reaches your CMS, framework or database.
| Attack | Example request | Result |
|---|---|---|
| SQL injection | /search?q=' OR 1=1-- | Blocked |
| Cross-site scripting (XSS) | /?name=<script> | Blocked |
| Path traversal and file inclusion | /../../etc/passwd | Blocked |
| Remote command execution | /?cmd=;cat /etc/shadow | Blocked |
| Sensitive file probes | /.env, /.git/config | Blocked |
| Vulnerability scanners | Known scanner signatures | Blocked |
| Protocol abuse | Malformed or unexpected requests | Blocked |
The OWASP Core Rule Set, managed for you
Shieldify uses the OWASP Core Rule Set (CRS), the open rule set maintained by the OWASP community and used by many commercial WAFs. Each request is checked against the rules; when the evidence adds up to an attack, the request is stopped at the edge and recorded with the rule that matched.
You do not install or update anything on your server, and there is no module to compile. The firewall runs in the same layer that handles DDoS protection and bot protection, so one request passes all three checks in one place.
Pick how strict each website should be
Every website has its own profile. Start with Medium and change it when the website needs something else.
Low
For sensitive applications where false positives must stay minimal. Catches the clear-cut attacks.
Medium
The recommended default. Blocks common exploits while keeping compatibility with typical applications high.
High
More aggressive detection for high-risk websites and periods of active abuse. Review the security events after switching.
Turn off one rule, not the whole firewall
Some applications legitimately send requests that look unusual, for example a page builder that posts HTML or a search box that accepts code. When one rule gets in the way, open Firewall rules for that website, find the rule by name or category and switch it off. Everything else stays active, and you can turn all rules back on in one click.
- Categories and single rules can be switched per website, for request and response checks.
- Security events show each blocked request with its path, the rule that matched and the time, so you can see what a rule actually stops before you change it.
- Changes apply live without downtime for your website.
Keep admin areas out of reach
Login and admin pages are where most exploit attempts land. With Zero Trust private pages you can protect paths such as /admin or /wp-admin/* behind an email access request. Approved people receive a time-limited code; everyone else stays out, and the request never reaches your application. No plugin or code change is needed.
Narrow exceptions for machines you trust
Payment callbacks, uptime monitors and office tools sometimes need a direct path. Under Access rules you can trust specific IP addresses or exact paths such as /api/payment/callback. Keep these rules narrow: a single path or address is safer than a wildcard.