Firewall: return to observation, identify the rule and add the minimal exception

But

This guide explains how to safely switch the firewall back to observation (monitor), identify which rule blocked a legitimate request, and then add the smallest possible exception to restore the desired action while maintaining effective protection.

Audience

• Site administrators using Securantis (WordPress/WooCommerce agent, PrestaShop module or the SaaS interface).
• Teams who want to react quickly to a legitimate block without opening the firewall too broadly.

Prerequisites

• Administrator access to the corresponding Securantis panel (WordPress plugin / PrestaShop module or the SaaS dashboard depending on your setup).
• FTP/SFTP access or file manager if a server file change is required (rare).
• Information about the blocked request: URL, source IP, timestamp and event type (e.g. SQLi, XSS, rate limit). The event table should contain these data.

Overview of the process

1. Return to observation (monitor) to avoid blocking other requests during diagnosis.
2. Reproduce or find the blocked event and collect its metadata.
3. Identify the rule and precise condition that caused the block.
4. Create a minimal exception (IP, path, parameter, header or targeted rule exclusion).
5. Test and return to blocking mode if everything is correct.

Detailed steps (procedure applicable to WordPress, WooCommerce, PrestaShop and the SaaS)

1. Temporarily switch to observation

• In the plugin/module interface or the dashboard, switch the firewall to observation/monitor mode. This prevents active blocking while continuing to log events.
• Keep this mode active for as short a time as necessary for diagnosis (typically a few minutes to an hour).

Expected result: the site is no longer blocked but events continue to be logged.

2. Gather information about the block

• Reproduce the legitimate action if possible (for example: submit the form or recreate the API request).
• Note or export the corresponding event: timestamp, full URL, HTTP method, body/parameters (if visible), source IP, user‑agent, firewall status (attack category: sqli, xss, etc.).

Tip: if the event was reported by a user, ask them for the exact time and the page involved to find the entry in the logs.

3. Identify the responsible rule

• In the firewall detections list, search for the event by timestamp and URL.
• Examine the details: most logs indicate the rule (or signature) that triggered the alert and the condition (parameter, header pattern, payload detected).
• If the log does not specify the rule, enable detailed logging temporarily for the same reproduction window and repeat the action.

Warning: avoid disabling entire categories (e.g. all XSS signatures) to identify a rule: prefer targeted logging and analysis.

4. Compose the minimal exception

Goal: open only what is necessary for the legitimate request.

Common types of exceptions

• IP exception: if the request originates from a stable and trusted IP address. Limit by duration and document the reason.
• Path/route exception: target the URL or prefix only (e.g. /wp-json/your-endpoint).
• Parameter exception: exclude a specific parameter known to contain characters detected as malicious.
• User‑agent or header exception: rare, but useful for legitimate API integrations.
• Disable a specific rule: if the system identifies a precise signature, create an exclusion for that signature only.

How to create the exception

• Choose the most restrictive exception type that resolves the issue.
• In the firewall interface, add the exclusion specifying the scope (IP, path, parameter, rule) and a short expiration time (e.g. 24–72 hours) if possible.
• Document the reason in the exception comment.

Expected result: the legitimate action succeeds without triggering the block, and the rest of protections continue to work.

5. Test and return to blocking mode

• Reproduce the action from the user’s environment (same IP / same application).
• Verify that the event no longer generates an active block but may still be logged.
• If everything is correct, switch the firewall back to blocking mode (block) to restore full protection.

Prudent settings and best practices

• Limit the duration of exceptions: prefer a temporary exception rather than a permanent exclusion.
• Favor path or signature exceptions over broad category exclusions.
• Document each exception (who created it, why, duration) for later audit.
• On WooCommerce and PrestaShop stores, prefer excluding specific checkout or known webhook routes rather than excluding AJAX globally.

Common mistakes

• Adding an exception that is too broad (e.g. disabling the entire XSS category) which exposes the attack surface.
• Forgetting to restrict the exception in time.
• Confusing server‑side blocking (e.g. .htaccess rules, WAF at the network level) with agent‑level blocking: check the origin of the block.
• Not reproducing the request from the same IP or with the same headers, which skews the diagnosis.

Troubleshooting (if the request is still blocked)

• Check the log immediately after a reproduction attempt: is another rule intervening?
• If the event has a different signature identifier, create an exception for that signature rather than expanding the previous one.
• Confirm that no other WAF (host, reverse proxy) is applying a similar rule.
• On WordPress/WooCommerce, ensure that sensitive AJAX and REST routes are not globally excluded; target the exact endpoint.

Security precautions

• Never ask for a password to perform these actions by email or chat.
• Files detected as malicious should not be automatically deleted: quarantine, restore or deletion require a human decision.
• If changing an exception requires a server intervention (configuration files), back up the files before modification.

When to contact Securantis support

Contact support if:

• You cannot identify the rule despite detailed logging.
• The minimal exception does not resolve the block and the site is impacted in production.
• You are unsure about the impact of the exception (e.g. critical route or high traffic).
• You suspect it is a disguised attack rather than a false positive.

Information to provide to support

• Exact timestamps of the reproduced events.
• Full URL, source IP and user‑agent used during reproduction.
• Screenshot of the event log if possible.
• Description of the desired solution (e.g. temporarily allow IP X for endpoint Y).

Conclusion

The golden rule: open only what is strictly necessary and for the time required. In observation mode, you can diagnose without affecting users and then implement targeted exceptions that restore legitimate operation while maintaining a high level of protection. If in doubt, contact support with the requested logs and details for guided assistance.