You can’t throw a stick into the WordPress community without finding a lot of information about security. Hack this, exploit that, the list goes on. Every WordCamp has a session on security. And companies like Sucuri do a bang-up job of fixing the problem if one does arrive. But what about preventative measures?
The Codex has a great write up on a lot of aspects surrounding security. But a close friend of mine was looking to accomplish something specific: restrict access to the login page to help circumvent brute force attacks. So after looking at core, I realized there is a
login_head hook that acts similar to
wp_head hook that we’ve all used. The below snippet checks for a specific query string, and if it either isn’t present or doesn’t have the correct variable, the page redirects.
After a conversation with a few folks, we realized that if your host doesn’t have output buffering enabled, this will fail. So the function has been modified to use the
init hook along with a
global $pagenow to check that you are on the login page. Also, there can be some quirks with the logout function itself.
Apparently I didn’t review the core file close enough, since there is indeed a
login_init hook to use, thus avoiding the entire
global $pagenow issue all together.
Will this prevent all possible exploits? Nope. Will this alleviate the need to keep core and plugins up to date, and use only secure, well written code? Not in the least bit. But it’s an additional layer that may be useful for some cases.