Dougal Campbell's geek ramblings

WordPress, web development, and world domination.

Creating a secure WordPress install

Over on BlogSecurity, there’s a whitepaper on How to create a secure WordPress install. It covers several areas, including MySQL setup, WordPress user configuration, Apache protection of directories, and some useful plugins. I’ve glanced over it, and I have mixed feelings. Here’s a quick list of notes, off the top of my head:


  • There is detailed information about granting the minimum privileges necessary for the MySQL login. This is a good idea that many people probably don’t think about.
  • Creating a less privileged WordPress account for posting, separate from your blog admin login, is also a good suggestion.
  • The notes on password enumeration are important. I didn’t even realize that we were giving different error messages depending on whether the username or password was incorrect. This is a definite no-no, and something that we should correct in the WordPress core.
  • For folks using Apache, and who can create .htaccess files, there is a good section on limiting access to wp-includes, wp-content, and wp-admin.
  • The WPIDS plugin sounds useful. This plugin will try to detect certain types of potentially harmful activity, log it, and possibly block further attempts.


  • There is a lot of space spent talking about changing the table prefix. This security-by-obscurity is probably going to be useless. If an attacker reaches the point that they can access your tables by name, then they’re most likely going to be able to figure out the names of the tables.
  • The section about restricting admin access by IP should probably be more detailed, and make it more clear that it is for advanced users, and probably not applicable for most users.
  • There is a section about the using the WordPress Plugin Tracker to make sure that your plugins are up-to-date. As of WordPress 2.3, there is built-in plugin version tracking, which isn’t mentioned in the paper. Granted, there are limitations (the plugin must be hosted in the repository), but I expect it to become more flexible in the future.
  • There is no mention about using SSL (https://...) for logins and admin functions. Since WordPress doesn’t support SSL out of the box, maybe that’s not surprising. But I think that I’ve seen some rumblings about supporting SSL in a future version.As of version 2.6, there has been support for SSL for logins and administration in WordPress.

Despite being a little light, I think work like this is important and useful. I’m hoping that the authors will take the constructive criticisms to heart and use it to update their paper, making it better and more thorough.

About Dougal Campbell

Dougal is a web developer, and a "Developer Emeritus" for the WordPress platform. When he's not coding PHP, Perl, CSS, JavaScript, or whatnot, he spends time with his wife, three children, a dog, and a cat in their Atlanta area home.
This entry was posted in Security, WordPress and tagged , , , , , , , , , . Bookmark the permalink.

31 Responses to Creating a secure WordPress install

  1. Network Geek says:

    Hmm, I have two thoughts on this, really.
    First, cool. It’s cool that people are looking closely at WordPress security. Especially people that aren’t heavily involved in development. Not only do they keep the developers on their toes, but, I hope, it gives them ideas to roll into the next version to make WordPress even more secure “out of the box”.
    Second, wow. Wow, I’m impressed that someone is serious enough about this to think that blog security deserves its own domain/site. I remember, back in the Dark Ages, when proto-bloggers did this all by hand and uploaded the HTML. Why, I had to walk up-hill, both ways, in a snow storm, just to get to my PC so I could blog! Once, I even had to strangle a bear with a CAT3 cable. Hmph.
    Seriously, we’ve come a long way, haven’t we?

  2. Pingback: La Biblia de la seguridad en WordPress | Mangas Verdes

  3. Ami says:

    Thanks for the post. I’ve been looking for information on this for awhile.

  4. Pingback: - Creating A Secure WordPress Install

  5. Pingback: Creating a secure Wordpress install at they made me do it

  6. Nick says:

    I was surprised too see no mention of SSL… I’ve spoken to the team about the fact that their .htaccess restrictions can also be applied in httpd.conf and the response was that the paper is aimed at the majority of users who don’t have access to httpd.conf, as such I would assume SSL isn’t included as not many bloggers have it and getting it then opens the whole certificate authority can of worms 😉

  7. Daniel says:

    I’m glad you pointed out the table renaming issue. I caught that as well when I read it.

    And given the reply that Nick received in relation to SSL — why would they be suggesting the renaming of table prefixes if they’re attempting to provide suggestions to the widest user-base? By renaming table prefixes, you’re essentially cutting the user-base off from upgrading properly.

  8. Pingback: WordPress Intrusion Detection: How to Block Hacking Attempts | WordPress Designpraxis

  9. Philipp says:

    Thanks Dougal for your coverage of our whitepaper. We know that the first version isn’t a perfect shot, and we got already many Feedback from the community on what to improve. And your Feedback is welcome as well, and as your Blog is although added into the WP-Backend you help to spread the word and improve the overall security of the WP community. We’re working already on a newer Version, and we plan to get it ready soon.

    @Daniel, I can’t really follow your thought about Prefix changing and cutting of the Userbase who can use it. I mean if everything is properly done within WP upgrades, which is the case as I use a different Prefix for my Blog with no Problems. The Upgrade routine will grab the Table-prefix from the config file, and all Queries are then done with the correct prefix, it would cause only Problems if somewhere the Table-prefix would be used hardcoded as “wp_”. Then you’re right it would cause problems on Upgrading of WP, or installing Plugins. But that’s bad programming Style.
    Another thought about Changing the Prefix, is that:
    1) not every Attacker may be skilled enough to find out the changed Prefix, but for sure he would be skilled enough to try the default one “wp_”
    2) If you would turn off the WPDB-Error Message you could, really improve the Security against SQL Injection flaws. Maybe we get someday a option to turn them off? Why not put something like an Error log into the Backend?
    Both mentioned points where as well mentioned by Stefan Esser

  10. Daniel says:

    Thanks for the clarification, Philipp. I suppose I’m looking at it with the angle of — that indeed, I think it could force manifestations of bad coding, which could potentially cause problems for the less experienced user-base.

    I just think there would or should be a more elegant approach to database security in that sense — and which doesn’t cause potential for breaking community support or perceptions.

  11. Philipp says:

    That’s right that less experienced user, would get into real trouble. And the current State that WP doesn’t offer a change off the prefix while the install Process could indeed bring some unexperienced programmer to the point to use the hardcoded way of “wp_”, which will work in 90%+ of the cases without problems. Anyway I can only recommend to apply a Prefix change to your install, it’s done within no time, through our plugin( surely you should create a Backup of your tables/database for the case something wents wrong, as we can’t guarantee that it will work on every Hosting configuration, with no problems).
    If this small change will add only a small amount to your security, wouldn’t it be worth? Additional if something shouldn’t work after update, you shouldn’t be shy to contact the Plugin author and ask for a fix/explanation, it will help future Users, and the developer to get a better programming Style.

    As we’re no gurus( or at least not in every area), we may don’t have the perfect solution available on beginning( as you can see for the htaccess rules).
    Currently we don’t know a better way to improve the security in the database area, if you can point us to some better one feel free to do so.

    My last point is that our Whitepaper is only supposed as an advisory on how to improve the security of your WP install. If you don’t want to apply a step you don’t have to, but we recommend it for a better security level. So if you don’t want to hit problems simply keep the table prefix!

  12. Tino says:

    Thanks for your comments mate.
    I’m gonna have a look at this whitepaper and check if is worthwhile the hassle.

  13. Pingback: Hardening Your Wordpress Blog

  14. Pingback: Wolly’s Delicious » Blog Archive » links for 2007-11-01

  15. Ehab says:

    This is a definite no-no, and something that we should correct in the WordPress core.

    Yes Indeed Master Yoda 🙂

  16. Pingback: Liquidmatrix Security Digest » New WordPress Security Whitepaper

  17. Ron says:

    Regarding WordPress and SSL there is the Admin-SSL plugin available, which ensures that all admin URL’s are accessed via SSL.

  18. Pingback: Andy Wibbels » WordPress Installations: How to Be Secure in an Insecure World

  19. thanks for the GREAT post! Very useful…

  20. John Yellow says:

    I’ve been looking for info on this matter for quite some time. Thanks for posting it! Especially table prefixes were something new to me.

  21. Pingback: » Blog Archive » Creating a secure WordPress install

  22. Pingback: WordPress Security Whitepaper Spanish Consejos de Seguridad Wordpress Descargar Gratis Full Megaupload Rapidshare Download Free Informatica

  23. Andy says:

    At the end of the day we will never be able to patch a hole before an update is released by WordPress. Other forms of security are our only ways forward, insuring we have protection at all levels, not just that our WordPress installation or version of MySQL are up to date. I recently came across this php firewall that blocks sql injections, xss, etc… logs DOS/DDOS attacks, the works. It really is fricking awesome:

  24. Andy says:

    Thanx for the info. That’s what’s I’ve been worried for a while

  25. Pingback: ????????????? ???????????? ??????? ??????

  26. I was wondering how to install secure wordpress. Thanks for writing useful post which helps

  27. Thanks for the lesson, i learn much.

  28. Bryce says:

    A three year old post and still accurate.  As so many things change it is strange how many things remain the same.  I wonder what your take on WP 3.0 is.

  29. Andrew says:

    Thanks for the post! I didn’t know about WP plugin tracker…

Leave a Reply to Andrew Cancel reply

%d bloggers like this: