A potential WordPress security issue can include access to the WordPress dashboard or administration screens. Because WordPress security already has role based access, this can be unnecessary. But that depends entirely upon the specific situation and your security policy.
Since every instance will be different, the decision to lock things down will be up to the site owner or administrator, but should you want to limit dashboard and back end access as part of your official WordPress security policy here are some things you can do to tighten things up.
Remove the WordPress Toolbar
A key step in WordPress security is not announcing to the world that you are running WordPress in the first place. For those running sites that have registered users who login, this will probably include removing the WordPress Toolbar (or WordPress admin bar).
The Toolbar concept was added to WordPress in Version 3.1 as Admin Bar and in Version 3.3 it was replaced by the Toolbar. If this is a WordPress security issue for your site, you can prevent the Toolbar from display by adding the following to your functions.php file:
// show admin bar only for admins
if (!current_user_can('manage_options')) {
add_filter('show_admin_bar', '__return_false');
}
Or perhaps you want to show the toolbar for admins and editors, but no one with a lower role than editor:
// show admin bar only for admins and editors
if (!current_user_can('edit_posts')) {
add_filter('show_admin_bar', '__return_false');
}
Limit or Prevent Dashboard Access
After removing the WordPress Toolbar, the next possible WordPress security issue may be dashboard access. The WordPress administration area already limits what is displayed to a specific user based on their role. But your site security policy may wish to include preventing or limiting this access to non-adminstrative users altogether.
Your WordPress security policy can include redirecting dashboard access to somewhere else on your site by redirecting users to a specific page if any admin screen is accessed by hooking the redirection to the admin_init action. This example will redirect any non-admin user to the home page:
add_action( 'admin_init', 'redirect_non_admin_users' );
function redirect_non_admin_users() {
if ( ! current_user_can( 'manage_options' ) ) {
wp_redirect( site_url() ); exit;
}
}
Redirect From the WP Login
The last potential WordPress security issue that I will discuss here includes redirection away from the default WordPress login. You can filter any places on your site that utilize a link to the default WordPress login, such as comment forms with the login_url filter.
It should be noted that if you employ a strategy like this, you will need to redirect to somewhere that the user can actually login, since admins will still need to be able to access a login. If a user is not logged in, you do not generally have a way of knowing if that user is an admin or not until they login, so you will need to provide some method of logging in on the site’s front end with a login process such as WP-Members.
add_filter( 'login_url', 'my_login_url', 10, 2 );
function my_login_url( $force_reauth, $redirect ) {
$login_url = 'http://www.domain.com/login-page/';
if( ! empty( $redirect ) ) {
$login_url = add_query_arg( 'redirect_to', urlencode( $redirect ), $login_url );
}
if( $force_reauth ) {
$login_url = add_query_arg( 'reauth', '1', $login_url );
}
return $login_url ;
}
Conclusion
It should be noted that this short article does not cover every possible WordPress security issue. This is only a discussion of some of the possible methods you might include in a more comprehensive WordPress security policy for your site.
For more information some common bad habits, WordPress security tips, and best practices, you should also review these posts as well:
