The 403 Forbidden Dance

Recently, this web site was plagued by a peculiar issue.

After modifying the content of a page within the WordPress editor, whenever I clicked the “Update” button, the following error message would be displayed and all changes would be lost:

You don’t have permission to access /wordpress/wp-admin/post.php on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

This would occur on every page on the site. I could not modify anything. But, surprisingly, I could create new pages.

It was puzzling, frustrating, annoying. Why was this happening?

The Internet is your friend, they say. Putting “403 Forbidden WordPress” in Google brought up more than 5,00,000 hits!

This was great! Everybody and their uncle had already faced this problem. A solution must be just a few clicks away. So, starting from the top, I clicked, and clicked, and clicked…

The solutions were varied. Some had solved it by adding or changing rules within the .htaccess file. Some had fixed it by ensuring that the permissions of the various files and directories in the website were correct. Some advised contacting the hosting provider to fix the security configuration of the web-server.

This problem apparently had multiple causes.

So I decided to implement the solutions one by one. First was to go through the permissions of each and every file and subdirectory on the site, and ensure that they conformed to what they should be. It was a useful exercise, since it helped to find and delete files not being used. But it did not fix the problem. I was still unable to edit any file in the website.

Next I checked the content of all the .htaccess files (there were several) and ensured that they contained what they should.

More important, I also added a directive to the .htaccess files which instructed the server not to scrutinize the content of pages. No luck, the problem was still present.

Since the permissions were correct, and the .htaccess contents were proper, it pointed to something on the server side which was responsible for this behaviour.

This was something for the x10hosting folks to look into. A couple of posts on the community support forums later, two rules on the server side were identified and disabled, one after the other. Disabling one rule did not fix the situation, but disabling the second one did.

Things came back to normal.

There was a mod_security rule on the server that got triggered by a script that was inside the page. This script was HTML-invisible. You would not see it when editing the page in the WordPress editor in visual-mode, but it would be visible as code when viewing it in text-mode.

The offending script was the Google Analytics tracking code!

If you want to have a particular page tracked by Google and want to know how many people visited it from where at what time, this is to be added to the page.

Infected by the enthusiasm that laymen commonly succumb to in matters relating to technology, I had added it to the end of every page.

The rule considered the Google script as malicious, and prevented me from modifying the page. This must have been a recent change on the server side, because the script had been present for some time without causing any issues.

And though I had included directives in┬áthe “.htaccess” file to ignore the content of pages, the security module installed on the server had been (re?)configured to ignore this directive.

The directive to the server to ignore content was ignored by the server!

Hence this problem, which was finally solved by the intervention of the server staff.

In my opinion, the .htaccess directives are there for a reason, and if some of them are disabled and configured to be ineffective, the same should be clearly mentioned somewhere so the user does not pull out his hair in frustration.

Hopefully, this problem won’t appear again.

I don’t know if there is a moral to the story, but perhaps someone, somewhere, might find it useful for her “403 Forbidden” issue.