Permission Denied 403 (Access Forbidden)

Debugging an elusive 403 error for a single page


I recently published a blog article that gave me a 403 Permission Denied (Access Forbidden) error whenever I tried to view it. The solution was simple, though not easy to come up with. I thought I'd post the story of my diagnosis and treatment here in case someone else has a similar problem.


 

MODX logo

 

Problem

The process of editing and saving the article was completely normal. It was the same process I used to save over 160 other blog articles. I couldn't see anything in the content of the article that might cause a problem. Whenever I tried to view the article, though, I got this:

403 Permission Denied

You do not have permission for this request

Diagnosis

In situations like this, I always delete all the files in the core/cache directory, and if that doesn't work, try another browser. Even after clearing the cache, I got the same error in any browser. The error came up *very* fast, which in retrospect should have been a clue.

My first thought was that it was an issue with mod_security, though I couldn't see anything in the content that would raise any red flags. I tried putting this in the php.ini file to turn off mod_security:

SecFilterEngine Off

When that had no effect, I wasn't sure if mod_security was really turned off (some hosts ignore the directive in php.ini). I deleted all the content in the article and replaced it with the word "test", but still got the 403 error.

This is approximately the point where hair begins to be pulled out. I checked to see if I got the error with pages that were not blog posts. I did not. I tried adding a new blog post to see if it would also be inaccessible. It was not. I tried deleting the whole article and creating a new one from scratch to see if the error was still there. It was.


The Solution

At this point, I decided to file a ticket with the host, since it was a server error and they were in charge of the server. I got a response saying that they checked the server logs, but couldn't find anything relevant. In other words, I was on my own.

I have a friend who knows almost nothing about computers or programming. When I have an intractable problem, I explain it to her and she pretends to follow what I'm saying. In at least two-thirds of the cases, a possible solution comes to me while I'm telling her why the problem can't be solved. As I was explaining it to her, I had a dim memory of creating some filters using rewrite rules in .htaccess to block malicious bots. At about that point, I realized that the pagetitle, alias, and URL of the article all contained the word "Admin".

I had spent time a while back looking at the output of the LogPageNotFound extra. It showed lots of bots, hammering away at the site looking for vulnerable files from various CMS platforms (I still see bots looking for the MODX "reflect" security hole, which went away years ago). It's wasteful of both time and resources to have the bots go through the entire MODX page-not-found loop for files that will never exist, so I created some rewrite rules in .htaccess that send a 403 response for them. The bots are often looking for a file or directory named "admin" or "wp-admin" (the place every hacker goes to exploit WordPress vulnerabilities).

As I suspected, this line appeared in my .htaccess file:

RewriteCond %{REQUEST_URI} admin [NC,OR]

The word "Admin" in the URL of the article was triggering that rule and causing the 403 error. I changed that line in .htaccess to this, and the problem immediately went away:

RewriteCond %{REQUEST_URI} wp-admin [NC,OR]
 

For more information on how to use MODX to create a web site, see my web site Bob's Guides, or better yet, buy my book: MODX: The Official Guide.

Looking for high-quality, MODX-friendly hosting? As of May 2016, Bob's Guides is hosted at A2 hosting. (More information in the box below.)



Comments (0)


Please login to comment.

  (Login)