Sometimes you don’t have control of the hosting a client is using, and you have to try and troubleshoot an issue.
In this case, updating a specific post resulted in a 403 forbidden status code in the
Chrome console as you can see below.
I started looking at Cloudflare as the potential issue and then WordPress. This was a huge waste of time and ultimately lead to frustration. Sometimes we want the solution to be simple and will forgo logical thought processes—many reasons why this occurs, including stress and potential lack of time. No one can avoid this as we’re humans. I didn’t want to disable Cloudflare completely, as this would change DNS and reactivating is somewhat instant. I didn’t want to chance accidentally going through Cloudflare. You would know if you were going through Cloudflare as Cloudflare headers would be added.
I then used another computer and bypassed Cloudflare by pointing the domain to the servers IP with a host file, this was a Windows 10 machine. The error still occurred, so it was definitely Siteground.
Then I clicked on payload and Response and saw branded Siteground 403 forbidden page was being returned. Validating further that it was Siteground, and would allow me to submit a ticket showing that Cloudflare wasn’t the cause. However, WordPress could be generating the 403 but it was very unlikely.
Once I figured out that Siteground was the issue, I looked at the access and error log on Siteground and found nothing, which was so strange.
I put in a ticket with Siteground, explaining the issue and providing the screenshot. They responded wanting to know the page in question as they were able to create a page and update it successfully. The post ID was in the screenshot provided, so it seems like it was glanced over.
After providing the page name, they replied back, stating that there were URLs in the database using http:// and https://, which would be regarded as mixed content and needed to be fixed using search and replace.
So I did a search and replace, found some URL’s and corrected them. I also corrected a URL in the theme file. The issue still occurred, and let Siteground know. Their response, the request was being blocked by modsec and that they’d disabled the rule in question blocking the request. Awesome!
Conclusion
Now, this all could have been avoided if the tech had looked at the screenshot and checked the logs. They even tried to update the post and received the error and still didn’t check the logs.
Secondly, they could report the 403 forbidden requests that are processed through modsec into the error log, which is standard practice. If you return an error code, it should be logged in the error log; that is the expectation.
Siteground mentioned that they couldn’t do this as it would reveal sensitive information. They don’t need to reveal this sensitive information; they just need to log the 403 forbidden and state why it occurred. A simple “blocked for security reasons, contact support”. This would then provide their client with a valid message and support with the information to resolve the issue quickly.