“My site is showing 403 Forbidden” is one of the more common tickets we get, and in almost every case nothing is broken. A 403 means a security layer looked at a request and refused it. On a WP Alpha server there are a small number of layers that can do that, and this article explains which one is likely to be responsible, how to tell, and what we need from you to clear it.
What a 403 actually tells you
Unlike a 500 or 504, which mean the server failed to produce a page, a 403 is a deliberate “no”. The server understood the request and declined it. That is good news: the site is up, the code runs, and the fix is a permission or rule change rather than a repair. The question is only which system said no.
Where 403s come from on WP Alpha hosting
Imunify Security on the server
Every WP Alpha server runs Imunify Security, which combines a web application firewall, bot protection and IP reputation blocking. It will return a 403 when a request matches a known attack pattern, when a bot ignores rate limits, or when an IP address has racked up failed logins. Typical real-world triggers: a staff member who mistyped a password a few times from the office, a plugin update that posts an unusual payload, or an external service polling the site aggressively. If you suspect this layer, open a support ticket with the IP address (or the service name and user agent) and the time it happened. We can see the exact rule that fired and allow-list the source in a few minutes.
A security plugin inside WordPress
Wordfence, iThemes/Solid Security, All In One Security and similar plugins add a second firewall inside WordPress. They are a frequent source of 403s on REST API calls, especially after you install a plugin that does something new. Start with the plugin’s own blocked-request log; it names the rule and the request. Wordfence has a learning mode that stops blocking for a period while it learns your site’s normal traffic, which clears most false positives. One thing to be aware of: Imunify already handles brute-force and malicious-request blocking at the server, so a heavyweight security plugin is often doing duplicate work and slowing the site for no gain.
Cloudflare in front of the site
If your domain runs through Cloudflare, its firewall sees the request before our server does, and anything it challenges or blocks never reaches us. The video above walks through a live example: a store’s Cloudflare rules were challenging all traffic from outside Australia, which also caught Jetpack trying to reach the WordPress API. The fix was a single custom rule placed above the others that skips the remaining rules when the user agent contains “Jetpack”. You can see what Cloudflare is blocking under Security, then Analytics or Events, and filter by user agent, IP or path.
How to work out which layer it is
- Look at the 403 page itself. A Cloudflare block shows Cloudflare branding and a Ray ID. A security plugin usually shows its own message (“Your access to this site has been limited by the site owner” is Wordfence). A plain server 403 with no branding points at the hosting layer.
- Check whether it affects everyone or one source. If only one IP, one country or one service is refused, it is a rule matching that source. If every visitor is refused, something broader has changed (a plugin update, a file permission change, or a .htaccess rule) and you should contact us straight away.
- Check the logs in the cheapest order: your security plugin’s log, then Cloudflare’s security events, then raise a ticket and we will check Imunify and the server logs.
What to send us in a ticket
- The URL that returns the 403 and roughly when it started.
- Who or what is being refused: your office IP, a named service (a payment gateway, Jetpack, an uptime monitor, a rank tracker), or all visitors.
- Whether the domain is behind Cloudflare, and if so whether you have changed any rules recently.
With that we can usually resolve a 403 in one reply. Remember that a 403 you did not ask about is normally the firewall doing its job; the ones worth chasing are the ones stopping something that should have access.