12 Essential Security Tips and Hacks for WordPress

WordPress is a great publishing platform, but it isn’t immune to all the potential attacks from hackers, spammers, and other ill-intentioned attackers trying to compromise the security of your WordPress installation.

12 Essential Security Tips and Hacks for WordPress

WordPress being open source means that the chances of malicious attacks being successful are higher because the project’s source code can be easily obtained and studied for vulnerabilities.

However, the good news is that there are steps that you can take to give your WordPress sites an extra layer of security.

This article highlights several tips and hacks that you can use to secure and lock down your WordPress site and to fortify it from attacks.

1. Back up your MySQL database regularly

You should always back up your site files and database. You should get into the practice of regular MySQL database backups by exporting your MySQL data as a .sql file to be stored in a safe location.

Back up your MySQL database regularly

I recommend at least making daily backups of your database; even if you are not updating your site often, you will be getting user comments and trackbacks all the time.

But manual backups are tedious and you’ll likely forget it or not do it regularly enough. To combat the human tendency to forget or put off boring and repetitive tasks, you should automate this process.

You can use the plugin called WordPress Database Backup to automate your backups. You can choose to make backups as often as you like and it provides you options such as hourly, daily, weekly, and monthly intervals. This puts you on the safe side because if your site’s database is compromised, you’ll have a backup to restore it to. There are other tools you can use for database backup automation, so explore your options and choose a method that works for you.

2. Take extra measures to secure your wp-admin folder

Take extra measures to secure your wp-admin folder

The wp-admin folder is a very important folder because it contains all of the files that deal with administration. If the security of the files in it is compromised, really bad things can happen not only to your WordPress installation, but the other stuff that’s on your domain.

You have several options available to you for making sure this folder is locked down tight. We’ll talk about a couple of them here.

One effective option to reducing the risk of a security breach on the wp-admin folder is by limiting the IP addresses that can access it via an .htaccess file (for Apache web servers). If you run another type of web server besides Apache (like IIS, which typically comes with a nice GUI out of the box), you may have to look into how to do similar permissions directives on your wp-admin folder.

To start, create a new blank document in your favorite text or source code editor (yes, this will work even if you use a simple text editor like Windows Notepad). Save this file with the name: .htaccess.

You can place directives similar to the code block below in your .htaccess file (modified from an excellent article on the BlogSecurity site, called "Hardening WordPress with htaccess").

order deny, allow
allow from 123.456.78 #Your IP Address
deny from all

Save the file and place it inside your wp-admin folder.

This option is nice and really tightens the security of your wp-admin folder, but it’s inconvenient if you work from multiple locations with different IP addresses.

Another way to add an extra layer of security to WordPress admin files is a plugin called AskApachePasswordProtect. The plugin gives you several additional security features such as requiring a username and password to access any administrative pages. It also writes the .htaccess file for you automatically (which is great if you’re not familiar with working on access control on Apache servers).


Check the documentation on the Apache site regarding how to use Authentication, Authorization, and Acess control to see how you can lock down other folders of your WP installation, as well as other locations outside of your WordPress install.

3. Don’t display your WordPress version number publicly

Many WordPress developers often display the WordPress version in the source code. But having this information publicly available makes it easy for attackers to exploit known vulnerabilities on a particular WordPress version.

It is safer altogether to remove this code. To do so, in your theme’s header.php file, look for code that looks something like the following code block and then remove it:

<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" />
<!-– leave this for stats please -->

If you can’t find the above code, yet you’re still seeing the meta generator tag in your site’s source, try looking for a PHP function call in your <head> tags.

<?php wp_head(); ?>

Study what things this function outputs for you, and just hardcode them into your theme files since these values will unlikely change. By default, this function outputs something like the following code block in your HTML source code:

<link rel="EditURI" type="application/rsd+xml" title="RSD"
    href="" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" 
    href="" />
<meta name="generator" content="WordPress #versionnumber" />

Just hardcode the first two lines (if you even need them). This has the added benefit of reducing server overhead due to this limited-purpose function call.

4. Keep your WordPress installation up to date

Keep your WordPress installation up to date

Since WordPress is an open source project, it is easier to find vulnerabilities in its source code. To make sure that you’re using the most secure version of WordPress, update your installation as soon as you can whenever the stable release launches.

You are taking unnecessary risks by not updating so if you have a WordPress installation that is at least two versions old, update it today! It literally takes 5 minutes according to WordPress.

5. Don’t use (or better yet, remove) the default "admin" username

When you install WordPress, it automatically generates a user with Administrator-level permissions called admin.

It is strongly recommended that you do not use this username to make it harder for the hacker to guess your username and password via Brute force attacks. Even if you downgrade its permission role, it’s still a better idea just to remove this user altogether.

To delete the admin user, first create a new user with the Administrator role through your WordPress Admin Panel (name it something that can’t be easily guessed). Then, with the newly-created user, delete the admin user. This technique saves you from doing this via MySQL query (or a MySQL GUI like phpMyAdmin).

In the subject of brute force attacks, you should also consider installing the Login Lockdown Plugin, which records the IP address and timestamp of every failed WordPress login attempt. If more than a certain number of failed attempts are detected from a particular IP address in short intervals, that IP address is blocked and no further login attempts are permitted from that address. You can configure this threshold to your preferences.

6. Encrypt your WordPress-related cookies

Encrypt your WordPress-related cookies

Another way to make your WordPress install secure is by encrypting the information stored in your WordPress cookies. This can easily be done using WordPress secret key generation tool. Get the random code from there, and paste it in your wp-config.php file.

This makes it hard to gain access to your WordPress administration panel by way of cookie hijacking.

7. Use a strong password

Use a strong password

Utilizing a complex password is probably one of the easiest preventative steps you can take towards improving the security of your WP install.

There many tools available on the web for verifying how strong your password is. For example, Microsoft has a free web-based tool on their site called Password checker. WordPress also has a built-in password strength verifier: please use it.

Check out this nice guide on guide at choosing a strong password at the Blog Herald.

8. Change your WordPress database table prefix from default settings

By default, WordPress uses wp_ as the table prefix for your MySQL database tables. To add a bit of security against SQL injection attempts, change this default value to something else.

WordPress recommends that you keep the prefix you choose to only to numbers and letters. I suggest changing it to something meaningful only to you like w0rdprss_ or yourblogname_.

To change the prefix, head over to your wp-config.php file and change the table prefix value.

$table_prefix = 'wp_';

Note that if you already have a previous installation of WordPress, you have to change your database table name to the prefix you assigned in wp-config.php or your site will stop working.

9. Use correct file permissions on your WordPress files

You need to make sure that all the files on your server have the right access rules in place. It is recommended that you don’t allow write access to any of your publicly-accessible files, but some WordPress plugins require that certain files and folders are writeable.

Configure your installation such that you only give all your files the minimum required permission. Usually, a CHMOD value of 644 (which means that the file is read-only) is enough. You should be concerned if you have to set a file to a CHMOD value of 777 (which means anyone can read, write, and execute it).

The way to determine if your site is at risk is to use a plugin called WP-Scan. This plugin scans for weaknesses in your WordPress blog related to file permissions (among other things).

10. Limit what search engine spiders can index

Your entire site doesn’t need to be indexed by search engine spiders (search engines are known to make it easy for attackers to find vulnerable and sensitive files via advanced search syntax). One way to do this is by limiting search engine spiders to indexing only relevant files and folders on your domain.

In the example below, you are telling search engines not to index anything inside folders that begin with the prefix /wp- (such as wp-login.php).

Disallow: /wp-*

You should read the tutorial on about WordPress robots.txt to learn about this subject in greater detail.

11. Use secured connections for accessing WordPress Admin pages

You can login to the WordPress Admin Panel through encrypted SSL connections. You need to see if your web host service gives you access to an SSL certificate first. Most likely, you won’t, but they’re cheap enough to have and worth spending a few bucks on.

Once you have an SSL connection, you can run your sessions on https:// instead of http:// protocols by forcing SSL connections on admin-related pages and functions.

You can do this by going in your wp-config file and inserting the following codeL

define('FORCE_SSL_ADMIN', true);

12. Lock down world-access to your wp-config.php file

As you can see from the tips discussed above, the wp-config.php file is an integral part of your WordPress install. It contains sensitive data such as your database username and password (which is used by WordPress to create a database connection to WordPress tables).

One thing you can do is to block world-access to the wp-config file is via .htaccess directives (for Apache servers). You can use the following code block as an example.

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

Another thing you can do is to move your wp-config.php file to a directory above of the default install location. This might seem strange, but according to the Official WordPress Codex article on hardening your security, it’s something you can do to reduce security compromises. Moving your config file adds an extra layer of security through obfuscation that can discourage many attackers.

Got more tips to share?

If you have more tips and WordPress hacks to secure it – please share it with all of us in the comments.

Related content

About the Author

Syed Balkhi is a professional Web Designer and WordPress Developer from Florida, USA. He is the founder of WPBeginner, a site that contains all sorts of articles for WordPress users. Check it out and subscribe to the news feed (link) if you like. He also runs Balkhis. Also, follow him on Twitter.

This was published on Jul 13, 2009


Empire Jul 13 2009

This is truly a valuable piece of information.

Jacob Gube Jul 13 2009

Hey everyone, just wanted to let you all know that this is a post that I’m proud to publish here on Six Revisions. I think Syed did a fantastic job and I’ll be trying to get him to write more posts for us. Also, follow him on Twitter (like I do) @syedbalkhi, he tweets about awesome design and development stuff.

Jim Gaudet Jul 13 2009

There are a few plugins to help with this too, but I also like to use the 4G Blacklist from Perishable Press…The WordPress firewall plugin will lockdown aspects of the admin section by IP address too,

Bariski Jul 13 2009

Nice article buddy. Want to add one more point:
Donot use the default admin account.

Jacob Gube Jul 13 2009

@Bariski: Syed noted that on #5, “Don’t use (or better yet, remove) the default “admin” username”.

Syed Balkhi Jul 13 2009

Thanks Jacob for publishing my article on Sixrevisions. It is an honor to write for this website and help secure more wordpress blogs.

Sumesh Jul 13 2009

Removing wp_head is a terrible idea, you’d often find plugins and hacks hooking into it to output stuff they need. By removing it,you risk a broken blog when changing anything.

A better idea is to use a little functions.php code to remove the tags, I wrote them on my blog.

Scott Jul 13 2009

I think you’re making the .htaccess suggestion overly complicated by instructing users to tie it to their IP address. My guess is that most people don’t have a static IP address, especially people for whom this tutorial might be geared. You could probably save some inexperienced users a huge headache if you left this line out.

theCount Jul 13 2009

Excellent article on an often neglected subject, I will be linking to this in a Tutorial on installing WordPress I am currently writing.
great work Syed and Jacob.

Ryan Rampersad Jul 13 2009

That Microsoft password strength checker doesn’t explain why a password is stronger than others, not as well anyway, as this one:
Also, I suggest using the secure secret key service.

mustaq Jul 13 2009


good list

but still you missed lot


change the path wp-content folder

change the path for login etc

mustaq Jul 13 2009

just a remider you can avoid from Brute force attacks

using a plugin which already in the wordpress plugin rack

where hacker or user can’t try more than 3 wrong password well later user have to request for forgot password to access again
Brute force attacks method try n number of time to guess the password

in my next comment i will post the plugin link

drupal Jul 13 2009

usually a lot of this kind of people hacks WP sites which are not updated coz its easy to navigate , also a tip better update your site from time to time

Lane4 Jul 13 2009

Most of these are obscurity rather than security tips. But thanks anyway.

Callum Chapman Jul 13 2009

Thanks for these tips. I’m terrible for not backing up my database!

Useful tips, but more than half of them are wrong or misguided…

#2 doesn’t add any real security, since most hacks happen outside of wp-admin.

#3 is totally useless, and even dangerous, as wp_head() is often critical to the operation of the site.

#5 is nice, but doesn’t really add any security. Brute force attacks are not a common way in.

#7 is built in, there’s a password strength meter in WordPress that actually works pretty well.

#8 doesn’t help from a good hack attempt.

#10 is actively harmful, as it prevents Google from indexing any of your uploaded images.

#12 makes sense, but since the wp-config doesn’t create any output on a server running php anyway, it won’t do anything.

Jeff Starr Jul 13 2009

I do not endorse #2. There are too many reasons why users, plugins, and scripts need access to the wp-admin directory. Locking it down with HTAccess sounds like a good idea, but may cause more problems than its worth.

For #3, instead of hardcoding stuff or messing with the wp_head(), you can remove the WP version output by simply adding this line to your functions.php file:

remove_action('wp_head', 'wp_generator');

#3: To remove the version number from your header add this to you themes functions.php file

/* Remove WP version in header */
remove_action(‘wp_head’, ‘wp_generator’);

Idris Jul 13 2009

Erm. The second paragraph shows how little the author understands about security. Rather spoilt it all for me, however beneficial the tips may be…

Way to miss the point completely.

peebee Jul 13 2009

Blah. Hook up the automatic database backup plugin, have them sent to your gmail account daily. Once your blog it built, save copies of the website files (configs, art, etc.) somewhere as well.

Your blog gets funky. delete your old database and reinstall a backup, reinstall the website pages along with the latest WordPress and go onto something more important. 10-15 minutes and you’re clean and done.

Thank you for this. It’s been extremely helpful, and u scared me just enough to make a bunch of changes – LOL

Rishabh Mishra Jul 13 2009

“WordPress being open source means that the chances of malicious attacks being successful are higher because the project’s source code can be easily obtained and studied for vulnerabilities.”

This is not true. WordPress being closed-source will not stop malicious hackers, but WordPress being open-source gives the “good guys” a better chance to finding and patching the vulnerabilities before they are exploited.

Joost Kiens Jul 13 2009

Nice list, but number 3 isn’t very good advice I believe. As others pointed out wp_head is critical and should not be removed.

To remove the generator meta tag, add the following line to your theme’s functions.php:
remove_action(‘wp_head’, ‘wp_generator’);

I cannot disagree more with the early reference to Open Source software being less secure. The transparency and open documentation of Open Source code is a primary reason why it’s MORE secure than closed, proprietary code. Serious exploits are typically addressed within a few days, in contrast to Microsoft where an online exploit can take weeks, months, and often years to be corrected. Stating vulnerabilities are easier to exploit using Open Source code is very misleading and false. Closed source, proprietary software make the issue of nullifying problems much, much more difficult.

Sankar Jul 14 2009

Thanks for the tips, I have to make sure about my word press blog that whether it’s protected or not.

Daniel15 Jul 14 2009

Using a username that can’t be guessed easily doesn’t do anything for security – The username is generally in the RSS feed anyways.

Also, SSL needs a dedicated IP address. Not all hosts offer this, you’ll want to check with your host to see (before buying the certificate!). I’d suggest the SSL certificates that offer, they’re really cheap and quite commonly used now. :)

Jacob Gube Jul 14 2009

@Jeff Starr, @Matt, and @Joost Kiens: Thanks for that tip, I’ll update this post with that snippet. Just sucks that that’s an extra function call, but it is the correct way of doing it. Although if I wasn’t using a plugin that required wp_head(), I’d hard code the value which would save me a couple of API calls (which probably trickles down to a few more PHP functions). For a distributed theme that I didn’t want to display the generator in – I’d definitely use the remove_action() function.

@Daniel15: Thanks for sharing. One note though: having a good non-standard username reduces the risks against bruteforce attacks that are usually scripted. So unless they have indeed devised a way to first check your RSS feeds for a username, it significantly reduces your vulnerabilities against automated attacks. Also, I’m not quite sure that the username is generally in the RSS feed, I guess if you don’t change your display name in the WordPress Admin area, then it will post your username as-is.

Thanks for the tips on SSL certs, I also would like to put in my two cents on that, SSLmatic sells reasonably-priced certs.

Kevin Quillen Jul 14 2009

You may also want to move /wp-admin/ to another path that is not easily guessed.

You can keep the admin name, you can have any name you want as a username, but I would highly recommend using a password generator like You’d be surprised how many peoples password is admin, or admin1, or bob123.

Great tips. I use Limit Login Attempts add-on for detect too many login attempts. You can control how many attempts, and length of timeout. It will even email me after a login block.

Michael Torbert Jul 15 2009

Great list Syed. I just wanted to point out that the WP Security Scan plugin actually does most of these for you:

what kind of problems will I have if i change the database table prefix after an installation has already been done? It’s enough to change the table names and config.php parameters? will the plugins still work ok?

Jacob Gube Jul 15 2009

@simo: You’ll have problems if you forget to update your wp-config.php file with the new prefix. But you should be alright. If you really wanted to do this the right way I wouldn’t do this on a live site and instead, just duplicate your current install on your local machine, check out my tutorial on installing XAMPP for local WordPress development.

Diane Bourque Jul 16 2009

Thanks for the great list – knew about lots of these issues, but picked up some new ones which are always useful.

Barry Hand Jul 16 2009

Really useful, especially on permissions which are very tricky to get right with WP.

tutorialslounge Jul 17 2009

there is great list for secure my blog, i’m still feeling scary about upgrade my wordpress version, due to my existing theme support confirmation, what can i do for this problem, have you any better idea for me???

Charley Jul 18 2009

“You’ll have problems if you forget to update your wp-config.php file with the new prefix. But you should be alright. ”

The ‘wp_’ prefix does not just occur in the main table names. It is used in references inside the database too. See this page:

This can cause you to get locked out.

Keith D Jul 19 2009

I like the idea of the “WordPress Database Backup Plugin”.

Does anyone know if it work with version 2.8?

Ivo Ivanov Jul 19 2009

@Keith D Yes, it works on WP 2.8

Great post!

Jenny Miller Jul 28 2009

This is great, and I really appreciate all of the information that you shared in this post!

Black Hattitude Sep 05 2009

Thanks a lot for all these tips!

Steve Sep 11 2009

From my research it seems like to use the media section you have to change the permissions on your server to 777 or 775? If you recommend not doing this then how do you get the media directory working?

Mas Dhani Sep 29 2009

In addition for WordPress security you need “Remove meta name generator WordPress” why? I think for avoid hacking by someone who want sabotage your wordpress.

Joe Lish Sep 30 2009

I used the code below to protect wp-admin. Now all users who go to the main page are being prompted the the “WordPress Admin Access Control” password rather than the password assigned to their subsriber accounts. If they hit cancel several times, the login page that uses the subscriber info appears. Any ideas?

AuthName “WordPress Admin Access Control”
AuthType Basic
AuthUserFile /homepages/**/********/htdocs/.htpasswd
order deny,allow
deny from all
require valid-user
# whitelist *****’s IP address
allow from **.**.***.***
Satisfy Any

Janvier Oct 26 2009

Of all, the last one seems the most interesting to me. Others are important too, but kind too trivial

viettel Nov 28 2009

to @Joe Lish: you can do the password protected directory easily from Cpanel web host control.

Chris McCorkle Dec 16 2009

Great post. Thanks Syed for helping us secure our installations!

About database backup: I use WordPress Backup (by BTE) on all of my clients’ WP installations. I have set up a few unique email addresses to which I have hourly backups emailed. It’s an offsite backup of sorts.

I tried step 2, and as a result was unable to access my wp dashboard. Then I tried this code from Cats Who Code:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName “Example Access Control”
AuthType Basic

order deny,allow
deny from all
allow from xx.xx.xx.xx

This time, I was able to log into WP dashboard.

Yanzen-Designer Jul 30 2010

Amazing idea pro. i love this blog, more i get trick from this blog. greats job ^_^

furrykef Aug 07 2010

The robots.txt example is slightly incorrect. It should read:

Disallow: /wp-

The asterisk after the hyphen is not needed and may in fact cause it to work incorrectly with some bots. Remember that the robots.txt standard specifies a simple substring search, so, unless you’re giving commands to a specific bot with known behavior, you should phrase your “Disallow”s as though they’re being matched with “if url.startswith(‘/blah’) …”

Thanks for all these tips!

Very useful. Thanks for all these tips!

Cat Lady Nov 02 2010

Bad ass! This is JUST what I needed…thanks! (=^_^=)

I think for avoid hacking by someone who want sabotage your wordpress :)

Cody Bonney Apr 09 2011

Great tips. I would leave out the one about only allowing access by single IPs via htaccess though. Most people these days have dynamic IP addresses.

Stanislav Jul 03 2011

Thanks for all tips! Really cool

Stoian Sep 14 2011

Thanks man … very very useful information for WordPress security

Anthony Sep 14 2011

HEY!, I made WordPress SQL Backup plugin at it does more than a database backup it also backs up your uploads, themes and plugins!

These are some good tips. There are plenty of users who leave their sites as default who are usually the ones who get hacked.

I have a list of some tips that I use for WordPress Security here:

This comment section is closed. Please contact us if you have important new information about this post.