10 Ways to Secure Your WordPress Installation

By Craig Buckler
We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now

WordPress is one of the most dangerous pieces of web software you can install on your server. A hacker can cause real havoc accessing your WordPress administrator account. Believe me, I know from firsthand experience!While hackers or spammers can maliciously delete or change content, the worst ones won’t. They’re more likely to sneak a few links into your content, or place phishing sites deep within your file structure. You’ll only know your site’s been compromised when Google, PayPal, or a bank contacts you.Changing your password isn’t enough, either. The first thing a hacker will do is install a file-browsing plugin. This will enable them to upload systems that could create additional WordPress administrator accounts or place further phishing pages on your site.

Installing for the first time?

If you’re embarking on a new WordPress installation, there are several steps you can take that provide additional security from day one.1. Use strong MySQL database namesI’d recommend using a new database for every WordPress installation. Just because WordPress can install tables within an existing database, doesn’t mean you should!Strong IDs and passwords are essential: avoid naming your database “wordpress” with a user ID of “user” and a password of “password.” You’re only likely to set these once, so they can be as complex as you like. If you forget them, you can check the details in wp-config.php.Finally, remember to back up your database regularly. Automate the process so it’s impossible to forget.2. Set a custom table prefixBy default, WordPress uses a table prefix of wp_—for example, wp_posts, wp_users, and so on. Change the prefix so that it becomes more difficult to run SQL injection queries and similar attacks.

Post-installation Security

You can add further security walls following a successful installation.3. Lock down wp-config.phpAs mentioned, wp-config.php contains vital information about your installation and only you should have access. The following entry in your root’s .htaccess file should prevent unauthorized copying:

<files wp-config.php>	order deny,allow	deny from all</files>

4. Avoid using the default “admin” IDPrior to version 3, WordPress set the ID of the first administrator account to “admin.” The version 3 installer gives you the option to change it, but I suspect many who updated from earlier editions never did.If a hacker knows your ID is “admin,” all they have to do is guess the password. It’s easy to define a new administrator account and then delete “admin” from the Users section. Remember to use a strong password too.5. Restrict access to your IP addressIf you only have a few WordPress users accessing the administration panels, you can restrict access to those IP addresses. If you’re using Apache, create an .htaccess file in wp-admin with the following code:

order deny, allowallow from # user 1 IPallow from # user 2 IP, etcdeny from all

Similar conditions can be configured for IIS.Note that you can’t use this method if you have a dynamic IP address; however, you could implement an extra level of basic server password authentication if necessary.6. Remove WordPress references from your themeA hacker will only try to hack WordPress if they know you’re using it. You can remove all references to the CMS and its version number within the theme files; for example, most header.php files contain code such as:

<meta name="generator" content="WordPress" />

Removing these references will fail to stop a hardened hacker, but it will make it less obvious to script kiddies.7. Update regularlyIf you’re still using WordPress 1.5, perhaps it’s time for an upgrade. Newer versions fix many of the publicized exploits and, by using the latest edition, you know hackers have had less time to hone their skills.8. Install good security plugins …The WordPress site has a collection of security plugins with useful descriptions and reviews from other users. The WP Security Scan plugin scans your WordPress installation for vulnerabilities and suggests security fixes.9. … but be careful what you installThe Web is awash with great and not-so-great free WordPress plugins and themes. Any of them could contain malicious code, handing over the driving keys to your installation. Be careful and, where possible, test code locally before deploying it to your live server.

10. I’ve been hacked! What do I do?

If you’ve received an email alerting you to phishing content on your site, I’d recommend the following course of action:

  1. Change all your site passwords, such as FTP, cPanel, SSH, and so on.
  2. If you have no recent database backup, export your articles to a WordPress XML file. Double-check it for any PHP code or unexpected content.
  3. Make a note of any plugins or settings you’re using.
  4. If absolutely necessary, download resource files such as images or videos, but check each one to ensure it’s what you expect.
  5. Wipe your files and database from your website. That’s all of them—not just the WordPress folders.
  6. Return to the top of this page and do a fresh reinstallation.

I bet you wish you’d secured WordPress earlier!Do you have any tips for improving WordPress security? Do you have any hacker scare stories?

note:Want more?

If you want to read more from Craig, subscribe to our weekly tech geek newsletter, Tech Times.

We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now
  • Heh, looks a lot like my list of almost 50 Joomla security tips, many of which applies to WordPress too:

  • We were hacked once. At the time I modified the permissions on the files, renamed some of the files, and of course changed passwords.

    For the locking down the config file, would I literally do a cut and paste from your example above into my htaccess file?

    • Thanks for the comment, chriscd. I had a site hacked too but, even after changing all the passwords and permissions, spammers were still uploading files using a hidden system somewhere on the site.

      You should be able to copy the config lock code into the .htaccess file in your root. Make a backup of the original .htaccess file before you do it.

  • sadara

    Thanks for the article, Craig; a lot of good thoughts!

    I checked out the ‘WP Security Scan’ plugin. It sounded like a good idea, but my experience makes me doubt that it’s to be wholeheartedly recommended, perhaps especially to someone who has just installed WP for the first time.

    There’s a function in the plugin allowing the user to change the table prefix. However, if for some reason the plugin does not have write access to wp-config.php, the tables are renamed but wp-config is not updated, making the site unusable. The fact that a number of values in a couple of WP’s config tables are also changed makes recovering from this no straightforward matter.

    • Thanks for the feedback sadara. I suspect most people’s wp-config.php will be writable because it’s written to during installation (in version 3+). Hopefully, that bug will be fixed in the plugin.

  • cookj128371

    Although security through obscurity is not a good practice by itself, something that can help hide your WordPress admin pages from people looking for them in the usual place (usually script kiddies) is to install WordPress to a folder with an obscure name (say, blackmothsuperrainbow), then move your index.php and .htaccess files from that folder to your web root. Next, update your index.php file and change this:
    to this:
    This tip comes from the book Digging Into WordPress, which I highly recommend for WordPress enthusiasts. Many other great security tips can be found at http://digwp.com/category/security/.

    • Thanks cookj128371. That’s an interesting idea — I initially thought that would be problematical, but all the WP file includes are relative, so it should be fine.

      The only issue is that links to JS and CSS files in your theme will reference a file in the obscurely named folder — hackers could see it. However, a mod rewrite could help solve that issue.

  • MissEm

    I read a great tip from the guys at “Digging into WordPress” that I use with every wordpress install.
    They suggested to rename the unzipped wordpress folder something really obscure then upload the folder to the root of the directory. Move the index.php and .htaccess file from the folder to the root directory.
    Open the index.php file and change “require(‘./wp-blog-header.php’);” to “require(‘./foldername/wp-blog-header.php’);”.

    When you are configuring the wordpress settings, point the URL to http://mydomain.com/foldername/ and the blog address to http://mydomain.com.

    As the guys say “Security through obscurity”!

  • WordPress is not one of the most dangerous softwares out there. The exploits that have made the new lately have had nothing to do with WordPress security. It’s entirely dealt with some hosts setting WordPress up in a terrible way or users using old versions of the software. Last I checked there were no security patches in the latest WordPress release because there were not any security holes in the software itself.

    None of your tips are actually modifying WordPress for security, they’re all just good security practice for any web application.

    All the tips are good but please revise that first paragraph to the truth and not some scare mongering designed to get clicks/links.

    • I agree that it’s not necessarily WP itself that’s a problem, but weak user names and passwords that hackers can break by brute force.

      However, I stand by my comment that WP can be more dangerous than other software. You can install plugins to upload files and modify databases with a couple of clicks. That’s great for hackers: few other products offer such deep customization and WP is one of the most-used CMSs on the web.

  • I have never used word press on my sites, but I have been hacked before. It was a really well done job, and I was luckly that I had my backups folder in some obscure location and they were auto created daily.

    If you want to go extreme with the security of the control panel try this – though it will not work on most shared hosting (and would be lest effective). Limit access to any critical part of the site to the servers IP. Then set up a ssh account with minimal privileges. Then use ssh with the -D option to set up a proxy to that server, and change your browsers proxy setting to use it. Don’t use a password for the ssh account either, set it up with a private/public key pair. If you possibly can, move the ssh port to something non default. Also nice because all traffic between you and the server remains encrypted.

  • Wolf_22

    I agree with curtismchale about his perspective regarding WordPress, and Craig, if your rebuttal is pertaining to WordPress plugins, then come out of the gates with that young man! :.P

    I’ll just come out and admit that my level of expertise in web development is far and slim compared to many currently in the field, but despite this, I have yet to have a single website using WordPress get hacked into–even one that’s very out-of-date with updates. Maybe I’m naive and have fallen victim to one of those nefarious scenarios where the bastard cracks into the system without my privy. Could be, right? In the end, though, I have yet to receive any cease and desist orders from anyone requesting that I remove whatever malicious program from my server, and this includes my own host… I’ve never seen any quirky functions or processes within the directories and coding and I’ve never seen any silly entries within my databases. And yes, my CPUs and everything else within my account works flawlessly.

    All this goes without saying that I HAVE had websites get hacked, just not with WordPress.

    For example, back in ’06 or ’07 I had a website using an obscure bare-bones CMS that got exploited by some jerk-off over in Russia (I’m assuming Russia because the control panel this disrespectful ass clown installed was all in Russian). He / she also installed some other “more bad stuff” written in C using a tunnel he or she created with that control panel which eventually led to a complete server reinstall. The way this happened was through an unsecured upload form where one thing led to another… Yes, it sucked, and it might have been avoided if my team back then was provided access to the server logs and not forced to use things we wanted to avoid using, but unfortunately, not all college administration types understand these things, especially the ones in Indiana.

    I’ve also seen situations where some idiot who pushes papers looks at his server logs only to see what he wants to see.

    For example, there was once a time not too long ago in fact where a supervisory type found some referrer strings that were generated by a rogue bot trying to inject malicious UNIONS into a query string meant for a Joomla install (hopefully you know what I’m talking about here; we all see these things from time-to-time). The string (I’m assuming) was some form of either XSS or Joomla exploit meant for older versions, I guess. Anyway, instead of just blocking the crapware within HTACESS and or doing whatever he or she needed to do in order to either update the Joomla install or even change a few passwords, they instead decided just take down THE ENTIRE SERVER and assume they were hacked–just because of 1 or 2 little weird looking entries in their logs… After looking through the entire install, database, and even Cascading Style Sheets for cripes sake, everything looked fine! What a joke. Like my peers, I wanted to believe they (the professionals responsible for taking the server down) knew something that we didn’t. So we politely asked someone to stop by our office to explain how the website was hacked. The person’s explanation?

    “I don’t know, I was just asked to take down the server.”

    Beautiful. So instead of learning from the given situation and actually doing something to improve things, we would rather just reinstall Windows (figuratively-speaking).

    Rambling aside and back to the main point: WordPress is not to blame here, Craig, even if it provides for plugins. These things are never black-and-white and often times wind up being amazing things thrown to the fire just because of some irresponsible bureaucrat’s attempt to stick within a comfort zone he or she found a job through…

    • I don’t think I ever said WordPress was to blame … after all, it’s the hackers who are ultimately at fault! However, because of its power and popularity, it’s an easy target.

      WP is a CMS so people won’t necessarily consider it a serious threat. Many will assume a hacker can only change or delete their posts, but WP (and its plug-ins) can do far more. Put it this way, I doubt many consider the strength of their WP password to be as important as FTP, Cpanel or SSH.

      That’s not a reason to blame or avoid WordPress. However, users should be aware of the risks and ensure they take basic steps to secure their accounts.

      • Wolf_22

        Sorry if I came off as aggressive, Craig. God only knows I had enough coffee in me this morning to run home on my hands…

        It’s just that when people get on that wagon about taking a deep breath in the way of WordPress, I get a little *touchy*. The reason for this is partially due to the whole “WordPress is not a CMS” argument, but also because I feel as if WordPress gets a bad name already, ya know? That’s all.

        Sorry again if I came across as one of those bipolar geeks who live in a dark room. Ha. Keep up the great work with your thought-provoking posts. I enjoy reading them! :.)

  • Hi Craig Buckler ,
    I loved the article. But I want to point you to make some correction’s as I feel so .
    I don’t feel the term Hacker is the one that you need . It should be cracker. You can see the exact definition of the both terms at http://www.ietf.org/rfc/rfc2828.txt .
    Sitepoint plays a good role on webdevelopers life. So I don’t want sitepoint to misguide someone . Also you don’t need to publish the comment , but may be good if you can make the correction .


    • Thanks harikt. I realize I should be using the term “cracker”. However, despite SitePoint’s technical user-base, I still consider “hacker” to be the more recognizable and understood term — even if it’s wrong!

      • :) . Thanks for your quick reply .

        May be good that you can point the ietf.org website, so others can also learn the exact term. For we all GNU / Linux users use the term Hackers and this will make confusion .

        I feel you need to make the correction as its read by a huge amount of people over the world and don’t want to mislead them again and again .

        Its upto you and sitepoint to decide :) .

        Happy Hacking ;)

  • bettybakebake

    I was really thrilled to read all the ways to thwart the ……ah…….crackers who …….ah……hacked my site…

    Anyway just a note. The demented one went in and changed my affiliate links to his own or someone elses. Hostgator chose not to prosecute. And I have no idea who to complain to. But it happened. Just thought you might be made aware of that.


  • husdaman

    Awesome, thanks. I applied these to our new wordpress 3.0 which was updated from wordpress mu. Helped us a lot.