WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For security in the production environment a company I work with has removed the whole wp-admin/ directory, and is about to disallow all *.php file calls with a 403 Forbidden HTTP error.

Are there any pitfalls to doing this? (Other than the obvious thing of now allowing administration or other backend functionality).

Are there any subsystems on the backend that I should be concerned with not working right if this is in place?

(Updates to content are done in a secure area, and the process of pushing to production replicates the database and WP files, except wp-admin/* files.).


share|improve this question
I don't understand how any of that could in any way improve your security. Also how you are supposed to do anything if you don't allow PHP POST, GET and REQUESTS. – Wyck Mar 9 '12 at 22:29
If the site uses jQuery Ajax call, would that break / stop the request? – Steven Mar 9 '12 at 22:30
Agreed - there are much easier and better ways to improve security. I'm somewhat curious to see if WordPress would even operate with *.php disallowed altogether. – SickHippie Mar 9 '12 at 22:33
To address the issue of why you might secure or remove wp-admin/ see: codex.wordpress.org/Hardening_WordPress#Securing_wp-admin – artlung Mar 9 '12 at 22:34
At that point what don't you just grab the feed, why the replication? – Wyck Mar 9 '12 at 22:35
up vote 1 down vote accepted

My understanding: They are going to disallow *.php access from external HTTP requests.

It should not cause a problem. It's a common security measure to disallow extension access, and if you are using custom permalink structures, you can get around most of the needs to do so.

Since quite a bit of your interactions with WordPress will be in the administration area, you shouldn't run into any problems with core features since you've sandboxed that somewhere else.

BUT, any plugins and themes that have made the assumption that they would be able to call AJAX via a *.php URL, or POST/GET from such a URL, may break. So using extensions may suck.

You may need to take more time in reviewing plugins and themes before saying "this will just work". By doing this, you will create more work for yourself in the long run for the trade of security.

Just to be sure, I would setup a default WordPress install, then setup custom permalinks...then leave it up for a bit and watch the access logs.

You can easily see how many hits are going to break because they directly hit *.php extensions.

A smoother way of doing this...might be to simply 301 people to mysite.com/whatevertheyweretryingtogetto.php -> mysite.com/whatevertheyweretryingtogetto

Just chop it off.

share|improve this answer
Yes, I've looked at some of the plugins we're using and we appear not to be using anything that has a "public-facing" .php file. I'll have to look at all of them a bit closer. Thanks for the coherent answer! – artlung Mar 9 '12 at 23:16
If it works out make sure to accept the answer! :-) – Sterling Hamilton Mar 9 '12 at 23:17

As I said in my comment, I'm no security expert. But I have worked in big firms that have had good security.

Here are a few things to consider:

  • Follow some of the more standard security measures of WP.
  • Rename /wp-admin
  • Move database to a server behind a firewall
  • Consider using a PROXY server
  • And if it is, as Sterling says common security measure, disallow extension access
share|improve this answer
wp-admin is indeed removed. database is indeed firewalled. whole site has a load balancing infrastructure in front of it with intrusion detection included. – artlung Mar 9 '12 at 23:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.