Sucuri and GoDaddy WAF Bypass Prevention Rules for Apache

admin

3 years ago

Apache WAF bypass prevention guide showing a protected website firewall path and safe verification checklist

A website firewall only protects the traffic that actually passes through it. If a visitor can reach the hosting server directly, the firewall may be skipped. That is why Sucuri and GoDaddy Website Security include bypass-prevention guidance for Apache sites.

This guide is for WordPress, cPanel, and Plesk sites that use Sucuri or GoDaddy Website Security in front of Apache. The goal is simple: keep public web traffic flowing through the WAF, avoid locking yourself out, and verify the site safely after the change.

Before You Add WAF Bypass Prevention

Do not paste firewall rules into production without a rollback plan. A small access-control mistake can block real visitors, scheduled jobs, payment callbacks, or even your own admin access.

Confirm DNS is already pointed at the WAF service and has had time to propagate.
Take a fresh backup of the site files and database.
Copy the current .htaccess file before editing it.
Know how to reach the site through cPanel File Manager, Plesk File Manager, SFTP, or SSH if the site returns a 403 after the change.
Check whether the same document root contains addon domains or subdomains that should not inherit the rule.
Plan a short maintenance window for busy stores, membership sites, or customer portals.

If this is a WordPress site, also review the cPanel WordPress hosting security checklist and the safe WordPress update guide. WAF rules help, but they do not replace clean plugins, current themes, patched PHP, or working backups.

Use The Current Vendor Rules

Use the current rule set from the Sucuri or GoDaddy dashboard for the protected domain. Do not reuse an old copied rule list from another website, another host, or an old tutorial. Firewall networks change, and stale allow lists can break traffic or weaken the protection.

In GoDaddy Website Security, the current path is under the site firewall settings, then the security section for preventing firewall bypass. GoDaddy provides server-specific guidance for Apache and NGINX. For Apache sites, the rule belongs in the site’s .htaccess file or in an equivalent Apache configuration location if your hosting plan gives you that level of control.

For Sucuri-managed accounts, use the Sucuri firewall dashboard or support-provided rule set for the protected site. If the dashboard gives different instructions than an older blog post, follow the dashboard and vendor support instructions.

Where The Apache Rule Belongs

On common cPanel hosting, the WordPress document root is usually public_html. On addon domains, subdomains, and some Plesk subscriptions, the document root may be different. Put the rule only in the document root that should be protected by that WAF configuration.

Be careful with shared document roots. If a parent .htaccess file controls multiple sites, a rule intended for one domain can accidentally affect another domain. When the host supports per-domain configuration, use the most specific location available.

Apache 2.4 uses the Require access-control syntax. Older Apache 2.2 examples used older allow/deny syntax and should not be copied blindly into a current server. When in doubt, compare the vendor instructions with Apache’s current access-control documentation or ask the host before applying the change.

Safe cPanel Workflow

Open cPanel File Manager and enable hidden files if needed.
Go to the protected site’s document root.
Download a copy of the current .htaccess file.
Add the vendor-provided WAF bypass-prevention block above general WordPress rewrite rules unless the vendor says otherwise.
Save the file and keep File Manager open until public checks pass.
Clear page cache, object cache, and any CDN cache that may hold old responses.

If the site immediately returns 403 for normal visitors, restore the backup copy of .htaccess first, then review the rule placement, DNS status, and vendor-provided network list before trying again.

Safe Plesk Workflow

Open the Plesk subscription for the protected domain.
Use File Manager or the domain’s Apache and nginx settings, depending on how the server is managed.
Back up the current .htaccess or Apache configuration before editing.
Add only the current vendor-provided rule set for the protected hostname.
Reload or let the hosting panel apply the configuration if server-level Apache settings were changed.
Check the public site, WordPress admin, checkout or forms, and scheduled tasks.

On a Plesk server with multiple subscriptions, avoid broad server-wide rules unless you are intentionally protecting every hosted domain through the same WAF path. Customer sites often have different DNS and firewall states.

What To Verify After The Change

Verification should prove the site still works for legitimate users. It should not involve public attack testing or exposing the hosting server address.

The homepage returns 200 through the public domain.
WordPress admin loads for an authorized administrator.
Contact forms, checkout, login, password reset, and API integrations still work.
Cron, webhook, and payment-provider callbacks are not blocked.
Access logs show normal public traffic arriving through the expected WAF path.
Error logs do not show a new wave of avoidable 403 responses for real users.
The WAF dashboard still shows current traffic and events for the protected site.

For WooCommerce or membership sites, test a real customer path from browsing to login or checkout. For business sites, submit a test contact form and confirm the message is delivered.

Common Problems

The whole site shows 403. Restore the saved .htaccess copy, then check DNS propagation, rule placement, Apache version, and whether the current vendor network list was used.

Only an addon domain is affected. The rule may be placed too high in the directory tree. Move it to the correct document root or use host-specific guidance from the vendor or hosting provider.

Forms, checkout, or callbacks fail. Review WAF logs, server logs, and plugin logs. Some third-party services need documented allow handling in the WAF dashboard or in the application, not broad origin exposure.

The site works for admins but not visitors. Clear site cache, CDN cache, and browser cache. Also confirm you are not seeing an authenticated preview while public users receive a cached 403.

When To Ask For Help

Ask the host, Sucuri, GoDaddy, or a WordPress security technician for help if the site uses custom reverse proxies, load balancers, multiple CDNs, payment callbacks, headless WordPress, multisite, or a mixed cPanel/Plesk migration. Those setups can be handled safely, but they need the actual traffic path mapped before access-control rules are tightened.

If you are cleaning up after a suspected compromise, do not stop at WAF bypass prevention. Review administrators, SFTP users, cron jobs, recently changed files, plugin versions, theme versions, and backups. For recent plugin examples, see the WP-Optimize patch guide and the Avada Builder patch guide.