Tuning the WAF

Sooner or later a WAF rule will block something legitimate: a page builder posting HTML that looks like XSS, an import tool sending SQL fragments, a plugin using a URL that looks like traversal. CorePanel gives you two tools for that, and the order in which you reach for them matters.

Is the whole client trusted (your office, a monitoring service, a payment callback)?
├── Yes → Trusted IP
└── No  → Is it one URL of one site misfiring on a known rule?
          ├── Yes → Exception (URL prefix + rule IDs)
          └── No  → Turn that specific rule off, per domain if your edition allows it
                    (turning a whole family off is the last resort)

Every step down that list costs you more protection. Stay as high up as you can.

Trusted IPs

A trusted IP skips WAF rule inspection entirely — rule phases and greylisting. Access control still applies: trusting an IP does not grant it access to anything, it only stops the firewall from inspecting its requests.

Use it for:

• your own office or VPN address while you debug something;
• an uptime or security scanner you run yourself;
• a payment gateway or webhook source whose callbacks trip a rule.

Entries can be single addresses or CIDR ranges (203.0.113.7, 203.0.113.0/24), IPv4 or IPv6. Each entry is validated as a real address literal, so a typo is rejected rather than silently producing a bypass that never matches. A list holds up to 200 entries.

Two levels:

Level	Applies to	Editions
Server-wide	Every site on the server	All, including Personal
Per domain	One domain only	Pro and above

Changes are applied on reload — no restart, no dropped connections.

A trusted IP is a hole, on purpose

An address on the list is unprotected. Never add a shared address (a whole datacenter range, a public proxy), and never add a CDN’s edge ranges — you would be trusting every request the CDN forwards, which is to say everyone. Review the list periodically and take out the temporary entries you added while debugging.

Exceptions

An exception is a scalpel: it skips specific rule IDs for requests whose path starts with a URL prefix, optionally narrowed to certain HTTP methods and client IPs.

Typical shape of a real one:

Field	Example	Meaning
URL prefix	/wp-admin/admin-ajax.php	Only requests to this path
Methods	POST	Only POSTs; GETs stay protected
IPs	(empty)	Any client — or restrict to your editors’ addresses
Rule IDs	XSS-002	Only this rule is skipped; everything else still applies

That exception lets a page builder save its content while leaving SQL injection, path traversal and every other XSS vector intact on the same URL — and leaving XSS-002 itself active everywhere else on the site.

Exceptions are per domain, and a domain holds up to 200 of them.

Writing a good exception

1. Find the event. The event log gives you the rule ID, the exact URL and the method.
2. Scope it to that URL, not to /. A prefix of / is a domain-wide disable of that rule with extra steps.
3. Name only the rules that actually fired. Not the family, not a guess.
4. Add methods when the false positive only happens on one verb — usually POST.
5. Add IPs when the legitimate traffic comes from a known place. An exception limited to your editors’ addresses is barely a hole at all.
6. Verify, then check the event log a day later to confirm nothing else broke.

Rule IDs, IP literals and method tokens are all validated, and a validation error points at the offending row — so a typo cannot silently produce an exception that never matches, or one that matches far more than you meant.

The protocol-integrity floor cannot be excluded

STD-004–STD-008 (null bytes, path traversal, CRLF injection) are refused in exceptions just as they are refused in rule toggles. A legitimate request never contains a null byte or a bare CR in a header — if one of these fires on your traffic, the traffic is malformed and the fix belongs upstream.

When an exception is the wrong answer

If a rule misfires everywhere on a site, an exception per URL is not maintainable — turn the rule off for that domain (Pro and above) or server-wide, and write down why.

If a whole family misfires, the assumption is wrong rather than the rule. Setting SQLI to detect for a while, watching the event log and then returning it to block with the right exceptions is a better route than leaving it off.

A tuning session, end to end

1. A customer reports a 403 on their site.
2. Event log, filtered by their domain: XSS-002, POST /wp-admin/admin-ajax.php.
3. Confirm it is legitimate — the timestamps match what they were doing.
4. Add an exception on that domain: prefix /wp-admin/admin-ajax.php, method POST, rule XSS-002.
5. Ask them to retry. It works.
6. The next day, check that domain’s log: no new blocks on that URL, and the other rules still firing on the attacks they should.