HTTP Guard
HTTP Guard is SHM's request-protection layer for hosted domains. Root defines whether the module is available and how its profiles behave; a domain remains unprotected until HTTP Guard is enabled for that domain in Web Manager.
Where to find it: Sign in as root, open Server > Configuration, then choose HTTP Guard.
Available to: Root only.
What this page does
Use this page for global module policy, allowed account overrides, monitor-only behavior, protected URI rules, smart-protection mode, bounded scan settings, and reusable profiles. Use Account > Web Manager for the final per-domain switch.
Before you start
HTTP Guard is not a network firewall and should not be enabled globally without an application baseline. Start with monitoring or a conservative profile where available, review matches, and test logins, APIs, uploads, carts, checkouts, and webhooks before enforcing broader rules.
Activation model
- Root makes HTTP Guard available and saves the global policy in Configuration.
- Root decides whether account-level overrides are allowed and defines profiles or smart-protection behavior.
- An authorized user opens the domain in Web Manager and enables HTTP Guard.
- The generated web configuration is applied for that domain.
- Logs and application tests confirm whether monitoring or enforcement behaves as intended.
Policy controls
| Control | Meaning |
|---|---|
| Allow overrides | Lets authorized account contexts choose supported domain-level policy rather than inheriting only the global value. |
| Monitor only | Records matching behavior without enforcing the same block decision; use it to establish a baseline. |
| Protected URI | Narrows protection to configured request paths where supported. |
| Smart protection | Off, monitor, or automatic behavior using the configured bounded analysis policy. |
| Scan bounds | Limits inspection work so request protection remains predictable under load. |
| Profiles | Reusable combinations of supported HTTP Guard settings. |
Web stack behavior
In NGINX reverse-proxy or NGINX standalone deployments, the public edge applies the supported HTTP Guard policy. In Apache standalone mode, Apache applies the supported module behavior. Always verify the active stack in Services instead of copying configuration advice from a different topology.
When not to enable it yet
Leave enforcement off while the site is already failing, while no representative traffic baseline exists, or while an application depends on unusual request bodies that have not been tested. Fix the application baseline first; adding a guard to an unknown failure mostly gives the failure a second name.
How to use it
- Confirm the active web stack and module availability.
- Choose a conservative global policy and save it.
- Open the target domain in Web Manager and enable HTTP Guard.
- Exercise normal and suspicious request paths.
- Review matches, narrow any exception, and move from monitor to enforcement only when evidence supports it.
Result and next check
The selected domain's generated web configuration reports HTTP Guard enabled with the intended policy, legitimate application flows continue to work, and matching unwanted requests are monitored or blocked according to the chosen mode.
Theme color