Applies to: Website owners, developers, and third-party security firms testing sites hosted by a Monarx hosting partner.
Summary
If ThreatShield blocks your penetration test, it is working as intended. Monarx does not disable protection rules or allowlist IP addresses for website owners or third parties. Requests about pentesting must go to your hosting provider’s support team.
💡 Only hosting partners can escalate to Monarx.
What is penetration testing?
Penetration testing (pentesting) is an authorized, simulated attack on an application or system to find security weaknesses before real attackers do. Testers commonly use automated scanners, fuzzers, brute-force tools, and hand-crafted malicious payloads. To a security product, a pentest looks the same as a real attack. That’s the point of the exercise.
Why your hosting environment matters
Your server type decides how much of the impact of a pentest stays with your site and how much spills onto others.
Shared hosting
Hundreds or thousands of websites share the same server: CPU, memory, disk I/O, network, and PHP workers. Aggressive scanning against one site uses resources every site on that server depends on. It can slow down or take down neighboring sites and trigger abuse or rate-limiting controls that affect other customers.
⚠️ Pentesting a website on shared hosting is not recommended.
Containers (container-based or “cloud” hosting)
Containers isolate sites better than traditional shared hosting, but they still run on a shared host kernel and shared physical hardware. Heavy testing can still hurt other tenants on the same node, and protection rules are usually managed by the hosting provider at the fleet level, not by the site owner.
⚠️ Pentesting here carries many of the same risks as shared hosting.
Dedicated servers / VPS
You control the full server, and the impact of testing stays mostly on your own infrastructure. This is the right environment for pentesting, usually against a staging copy of the site. Even here, check your provider’s acceptable use policy first, since testing traffic can still trigger network-level abuse detection.
🏁 Best practices for pentesting
Test a staging copy, not production. Clone the site to an isolated environment (ideally a dedicated server or VPS you control) and test that copy.
Read your hosting provider’s pentesting policy first. Most providers publish rules on whether testing is allowed, what scope is permitted, and whether advance notice is required.
Get written authorization from your hosting provider, not just from the website owner. On shared infrastructure, the site owner can’t authorize testing that affects the provider’s servers.
Define scope and limit intensity. Throttle request rates, avoid denial-of-service style testing, and stay within the agreed targets and time window.
Test your application, not the hosting platform. The provider’s security controls (including ThreatShield) are part of the platform, not part of your application’s attack surface.
Treat blocks as findings. If ThreatShield stops an attack technique in production, real attackers using that technique will be stopped too. Record it in your report as a mitigating control.
⚠️ The risks of disabling rules or allowlisting testing IPs
Asking for ThreatShield rules to be disabled, or for a testing IP to be allowlisted, may seem harmless for a short test window, but it creates real risk:
It removes protection for real attacks. An allowlisted IP or disabled rule doesn’t know whether traffic comes from a tester or an attacker. Testing IPs can be shared, spoofed through proxies, or compromised, and testing infrastructure often shows up in public scan data.
It exposes other websites. On shared and container hosting, protection rules are set across the whole fleet. Weakening them for one site can lower the protection of every site on the same server.
It produces misleading results. Testing with protections off measures a setup that doesn’t exist in production. The report will list vulnerabilities that real attackers couldn’t exploit, and it won’t reflect your site’s actual security posture.
Exceptions get forgotten. Temporary allowlists and disabled rules that aren’t cleaned up after a test leave gaps in protection that last long after the test ends.
✅ If ThreatShield is blocking your pentest, it’s working as intended
ThreatShield is a runtime protection layer (RASP) deployed by your hosting provider. Its job is to detect and block malicious behavior: exploit attempts, vulnerability probing, malicious uploads, and suspicious requests. When a pentest is blocked (for example, with an HTTP 403 response), that is ThreatShield doing exactly what it was deployed to do. It is not a false positive and not a malfunction.
🔍 Monarx’s policy on allowlist and rule-disable requests
Monarx provides ThreatShield to hosting partners, and each hosting partner sets and manages the protection rules across its own fleet. For that reason:
Monarx will decline any request from website owners or third parties (including security firms, agencies, and auditors) to allowlist IP addresses, disable protection rules, or otherwise change the protections a hosting partner has configured.
This applies no matter the scope, duration, or authorization documents of the test.
Only hosting partners can escalate to Monarx. We can’t act on requests that come directly from website owners or third parties, and we can’t share event data for a partner’s servers with them.
What to do instead
Contact your hosting provider’s support team directly. They own the server and its security configuration.
Review your provider’s pentesting guidelines and follow its process for authorized testing.
Ask your provider about alternatives, such as testing a staging copy on a dedicated environment.
If your hosting provider decides Monarx’s help is needed, they will escalate to us through their partner support channel.