A ModSecurity rule hit can explain why a legitimate form submission or upload receives a blocked response. Identify the exact request and rule before changing firewall behaviour.
IN THIS ARTICLE
What you need before you begin
Collect the domain, request path, time zone, timestamp, response code and a safe reproduction. Avoid recording passwords, payment data or private form contents in a support ticket.
01 Find a ModSecurity rule ID for a blocked customer request
- Open ModSecurity Tools > Hits List in WHM with authorised access.
- Locate the event matching the domain and reproduction time. Record the rule ID and available request details.
- Open the rule information and compare its purpose with the application action. Check the underlying audit logs if the summary does not show the complete sequence.
- Confirm that the request is legitimate and whether an application update or malformed payload explains the match.
- Provide the verified rule ID and redacted evidence to the responsible administrator or rule vendor before planning a narrow exception.
Confirm the expected result
The investigation should connect one reproducible request with the relevant protection event. A rule appearing nearby in time is not sufficient proof that it caused the user’s failure.
Troubleshoot unexpected results
The Hits List displays a selected relevant hit, not necessarily every rule event for a request. A CDN firewall, application permission or web-server rule can also return a similar status. Avoid disabling ModSecurity across all domains while searching for the cause.
Should I publish the full audit entry?
No. Audit details can contain request data and identifiers. Share the minimum necessary evidence through a trusted support channel and redact secrets while preserving the diagnostic fields.