When was the last time you logged into your WordPress site? What user level did you log in with?
Is your default account an Administrator? Were you logging in to perform administrative actions or to write a post? To update user preferences or moderate comments?
We’re lazy, so once we have a single WordPress login, we tend to use it for everything. I’m no different – I often use the same login to draft posts on my site that I use to administer my site’s settings. It’s a bit of a security issue, actually.
Imagine if every task you ran on your local machine was run with administrative privileges. For the most part, we understand this is a bad idea and hide our administrative accounts behind redundant password screens or [cci]sudo[/cci] access. It helps prevent unintended changes to the system and helps protect against hijacked sessions from being used to irreparably damage a machine.
Why do we treat WordPress differently?
Poor Development Practices
Developers are often just as lazy as, if not lazier than, the users of their end product. As a result, we often take shortcuts – copy/paste code from one project to another, skip writing unit tests “just to get it done,” use code generators to flesh out an application with methods and objects that aren’t really necessary.
We build code to do a job, but often want to complete it so quickly that we do, frankly, a crap job at writing our code.
In the WordPress world, one of our biggest sins is the misuse and abuse of user permissions.
How often have you written [cci]current_user_can( ‘manage_options’ )[/cci] when building out an administrative panel? This is a useful way to prevent subscribers – or any low-permission logged-in user – from seeing or manipulating your settings panel. But it also means you’re locking things down to just Administrators by default.
You’re also encouraging your customers to log in to their administrator-level account whenever they need to do non-administrator things.
Instead, we need to work harder as a community to:
- Understand the permissions we actually need to extend to customers to perform actions within our software
- Take the time to establish new capabilities within WordPress rather than blindly reusing some built for other purposes
- Train our customers to properly audit and account for permissions within their site
We can build a better, more secure WordPress ecosystem. To do so, we need to stop being lazy about security.
