A single leaked admin account can change the course of an entire website: pages can be altered, malicious plugins can be installed, user data can be downloaded, and even access to the server can be exposed. The problem is that many website owners still believe security is complete after installing a strong password and security plugins.
In fact, there is another layer that is often overlooked: who can do what? This is the realm of authorization, which is the process of determining the actions and data that can be accessed by users who have successfully logged in. Someone may be authenticated, but that does not mean they need access to all menus and functions.
The simple principle is least privilege: grant the minimum permissions necessary to complete the job. If someone only writes articles, they do not need the ability to install plugins. If an application only needs to read product data, its database account should not have the rights to delete entire tables.
The OWASP guidelines place access rights restrictions, default denial of access, and permission checks on every request as essential foundations of application security. OWASP explains this principle in the Authorization guide.
Why is a single admin account for everyone dangerous?
Using a shared account may seem practical. Everyone knows the username and password, and no time is wasted setting up new accounts. However, this practice obscures three important things.
- Activity trail: when suspicious changes occur, it is difficult to know who made them.
- Access control: everyone has the same permissions, even though their responsibilities differ.
- Access revocation: when someone stops working, the password must be changed, and everyone needs to be informed.
It is safer for everyone to have personal accounts. This way, access can be revoked without disrupting other users, and activity logs can be linked to clear identities.
For daily tasks, also separate regular accounts from administrative accounts. Admin accounts should only be used when it is necessary to change configurations or install updates. Activities such as reading emails, opening links, or managing routine content should be done from accounts with lower privileges.
WordPress: do not make everyone an Administrator
WordPress already provides a system of roles and capabilities. A role is a group of users such as Editor, Author, or Administrator, while a capability is a specific permission that determines what actions can be taken.
Editors, for example, can manage content but do not automatically have permission to change core configurations or install plugins. Administrators have a much broader scope. Therefore, granting the Administrator role just because someone needs to publish a post is too lenient a decision.
The official WordPress documentation recommends that plugins and features check for the appropriate capabilities, rather than just relying on the fact that the user is logged in. This is especially important for plugin or theme developers who create new settings pages and endpoints.
In WordPress code, checks like current_user_can() need to be performed before sensitive actions are executed. Simply hiding menus from the dashboard is not enough. Users can still attempt to access URLs directly if the endpoint does not perform permission checks on the server side.
Do not just secure the interface, secure every request
One common mistake in secure coding is assuming that hidden buttons mean that the function is secure. In fact, attackers can send HTTP requests manually without going through the interface created by the application.
Therefore, every request that modifies data, deletes objects, uploads files, or changes configurations must check at least:
- Is the user logged in?
- Does the user have the correct capability?
- Is the requested object owned by or accessible to that user?
- Does the request have CSRF protection, such as a nonce in WordPress?
- Is the data received validated and constrained?
The practical rule is: if permission is not explicitly granted, deny the request. The pattern of “allow all, then block some cases” is more likely to produce vulnerabilities when new features are added.
Login sessions also need to be treated as sensitive access
Passwords are not the only entry ticket. After logging in, the browser stores a session identity that allows the user to remain recognized by the server. If this session is stolen, an attacker can act as the user without knowing the password.
For PHP applications, sessions need to be managed carefully. The session ID should be changed after a successful login or when the user's access rights are elevated. PHP documents the use of session_regenerate_id() as part of protection against session fixation, which is a situation where an attacker tries to force a victim to use a known session ID.
Also use cookies with Secure, HttpOnly, and SameSite attributes as needed by the application. Logout must completely invalidate the session on the server side, not just remove the display from the browser.
Steps to take this week
- Audit all accounts. Record who has access, when it was last used, and why that access is still needed.
- Remove old and shared accounts. Create personal accounts so that activities can be tracked.
- Reduce overly high access rights. In WordPress, use Editor, Author, or custom roles if Administrator is not necessary.
- Separate daily accounts from admin accounts. Do not use accounts with the highest privileges for regular activities.
- Check sensitive endpoints. Ensure that every function on the server checks permissions, not just hides buttons.
- Enable multi-factor authentication. This helps reduce the impact when passwords are stolen, although it does not replace access restrictions.
- Keep useful logs. Record logins, role changes, plugin installations, configuration changes, and data deletions.
- Test recovery. Ensure you know how to revoke sessions, disable accounts, and recover the website in case of an incident.
What does this mean for us?
Access restrictions do not mean distrust in the team. On the contrary, it is a way to keep the system secure when humans forget, devices are infected, or a single account falls into the wrong hands.
Good security does not just try to prevent attackers from getting in. It also limits what can be done once access is obtained. With personal accounts, proportional roles, server-side permission checks, and clear logs, a single mistake does not have to turn into damage to the entire website.
The documentation Hardening WordPress also emphasizes the importance of access restrictions, regular updates, component separation, and recovery preparation. No configuration makes a website immune forever, but a well-designed access scheme can make incidents smaller, easier to trace, and quicker to recover from.
Sources & further reading
- OWASP Authorization Cheat Sheet
- WordPress User Roles and Capabilities
- WordPress Hardening Guide
- PHP Session Management Basics
- PHP session_regenerate_id()
– Rio Yotto @rioyotto