What is the principle of least privilege for website access?

The principle of least privilege means that every person, program, and process connected to your website should have only the minimum access it needs to do its job, and only for as long as it needs it. An editor doesn't need administrator rights, a contact form's API key doesn't need permission to delete your email account, and a web server process doesn't need to write to your theme files. When something goes wrong, least privilege limits how far the damage can spread.

Most website breaches don't start with a dramatic zero-day exploit. They start with a stolen password, a vulnerable plugin, or a leaked key, and the real damage depends on what that compromised account or process was allowed to do. This article explains the principle in plain terms, then shows you how to apply it across the layers of a typical website: user accounts, hosting and infrastructure, the database, the file system, API keys, and servers.

What Does Least Privilege Actually Mean?

Least privilege is a simple idea with a long history in computer security: give out access on a need-to-have basis, not a nice-to-have one. It applies to three kinds of "subjects":

• People: Administrators, editors, developers, freelancers, support staff.
• Applications: Your CMS, plugins, scheduled jobs, deployment tools.
• Machine credentials: Database users, API keys, SSH keys, service accounts.

For each of them, you ask two questions: what's the smallest set of permissions that still lets this work, and how long does this access need to exist?

Why It Matters for Websites

Think of least privilege as damage control. You can't guarantee that no account will ever be compromised, but you can control what an attacker gets when one is.

• A phished editor account with only the Editor role can deface posts, but can't install a malicious plugin or create new admin users.
• A vulnerable plugin running on a server where PHP can't write to the plugin directory can't easily drop a backdoor into your code.
• A leaked API key that can only send transactional email can't be used to export your subscriber list.
• A compromised database user limited to one database can't read the data of other sites on the same server.

Least privilege also reduces mistakes. People with fewer permissions have fewer ways to accidentally break things.

Related Ideas

You'll often see least privilege mentioned alongside a few related concepts:

• Separation of duties: No single person should control every critical step, such as both writing and approving payments.
• Just-in-time access: Access is granted temporarily when needed, then removed automatically.
• Zero trust: Every request is verified, regardless of whether it comes from "inside" your network.
• Defence in depth: Multiple layers of protection, so one failure doesn't expose everything.

Applying Least Privilege to CMS User Accounts

Your CMS is where least privilege is easiest to start. WordPress, for example, ships with five main roles: Administrator, Editor, Author, Contributor, and Subscriber. We cover these roles in detail in a separate guide, so here's the least-privilege view of them.

1. Audit existing users: Go to Users > All Users and filter by role. Count your administrators. On many sites, that number is higher than it should be.
2. Match roles to real tasks: Someone who writes and publishes their own posts needs Author. Someone who manages everyone's content needs Editor. Only people who install plugins, change themes, or manage users need Administrator.
3. Downgrade where possible: Change unnecessary administrators to Editor or lower. Most content teams can work entirely without admin rights.
4. Remove inactive accounts: Former staff, old freelancers, and test users should be deleted, with their content reassigned to an active user.
5. Separate your own accounts: Consider having an Editor account for daily writing and an Administrator account you only use for maintenance.

You can list administrators quickly with WP-CLI:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Create Custom Roles When the Defaults Don't Fit

Sometimes you need something in between. For example, a shop assistant who only manages WooCommerce orders, or a marketer who only edits pages. You can create a narrowly scoped role in a small custom plugin:

<?php
/**
 * Plugin Name: Sajjad Custom Roles
 * Description: Adds a restricted Page Manager role.
 */

register_activation_hook( __FILE__, 'sajjad_add_page_manager_role' );
function sajjad_add_page_manager_role() {
    add_role(
        'page_manager',
        'Page Manager',
        array(
            'read'                   => true,
            'edit_pages'             => true,
            'edit_published_pages'   => true,
            'publish_pages'          => true,
            'edit_others_pages'      => true,
            'upload_files'           => true,
        )
    );
}

register_deactivation_hook( __FILE__, 'sajjad_remove_page_manager_role' );
function sajjad_remove_page_manager_role() {
    remove_role( 'page_manager' );
}

Roles are stored in the database, so they're added on activation rather than on every page load. Plugins such as Members or User Role Editor provide a visual interface for the same job if you'd rather not write code.

Check Capabilities in Your Own Code

If you build custom admin screens or AJAX handlers, check the specific capability the action requires, not just whether the user is logged in:

<?php
add_action( 'wp_ajax_sajjad_export_orders', 'sajjad_export_orders' );
function sajjad_export_orders() {
    check_ajax_referer( 'sajjad_export_orders', 'nonce' );

    if ( ! current_user_can( 'manage_woocommerce' ) ) {
        wp_send_json_error( array( 'message' => 'You do not have permission to do this.' ), 403 );
    }

    // ... perform the export
    wp_send_json_success();
}

Many plugin vulnerabilities come from exactly this mistake: an action that only checks is_user_logged_in(), so any subscriber can trigger it.

Applying Least Privilege to Hosting and Infrastructure

The accounts above your CMS are even more powerful, because they control the whole site.

• Hosting control panels: If your host supports team members or sub-accounts, give developers access to only the sites they work on, and billing staff access to only billing.
• Registrar and DNS: Very few people need to change DNS. Cloudflare, for example, supports roles like Administrator Read Only, DNS, and Firewall, so you can grant exactly what someone needs.
• Cloud providers: On AWS, Google Cloud, or Azure, use IAM roles and policies scoped to specific resources instead of sharing the root account. Lock the root account away with a hardware key and use it only for emergencies.
• Git and deployment platforms: Give contributors write access only to the repositories they work on, protect your main branch, and require reviews before deployment.

Applying Least Privilege to the Database

Your website's database user usually has far more rights than it needs. Many setups use a single user with ALL PRIVILEGES on every database, or even the MySQL root account.

At a minimum, each site should have its own database and its own database user limited to that database:

CREATE DATABASE example_wp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'example_wp_user'@'localhost' IDENTIFIED BY 'a-long-random-password';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP
    ON example_wp.* TO 'example_wp_user'@'localhost';
FLUSH PRIVILEGES;

WordPress needs CREATE, ALTER, INDEX, and DROP for core and plugin updates that change the schema. If you want to go further, some teams use a separate, more privileged user only during updates, but that adds complexity and isn't necessary for most sites.

Other database least-privilege steps:

• Restrict the host: 'user'@'localhost' only allows local connections. Avoid 'user'@'%' unless remote connections are genuinely required.
• Use read-only users for reporting: Analytics dashboards or BI tools should connect with a user that has only SELECT.
• Don't expose phpMyAdmin publicly: If you need a database tool, restrict it by IP or remove it when you're done.

Applying Least Privilege to Files and Directories

On a Linux server, file ownership and permissions decide what the web server process can change. A common secure setup for WordPress is:

• Directories: 755
• Files: 644
• wp-config.php: 640 or 600, depending on how PHP runs

You can apply those from the WordPress root with:

find /var/www/example.com -type d -exec chmod 755 {} \;
find /var/www/example.com -type f -exec chmod 644 {} \;
chmod 640 /var/www/example.com/wp-config.php

The more important decision is ownership. If the web server user (often www-data on Debian and Ubuntu, apache or nginx on RHEL-based systems) owns all your files, then any PHP vulnerability can rewrite any file. A more restrictive approach is to have a separate deploy user own the code, with the web server only able to write to wp-content/uploads:

sudo chown -R deploy:www-data /var/www/example.com
sudo chown -R www-data:www-data /var/www/example.com/wp-content/uploads

This means WordPress can't update plugins through the dashboard, so you'd update via WP-CLI as the deploy user, SFTP, or a deployment pipeline. It's a trade-off: more secure, slightly less convenient. Test carefully and take a backup before changing ownership on a live site.

You can also stop administrators from editing theme and plugin code in the dashboard by adding this to wp-config.php, above the "That's all, stop editing!" line:

define( 'DISALLOW_FILE_EDIT', true );

Applying Least Privilege to API Keys and Integrations

Modern websites connect to many services, and each connection is a credential. Apply least privilege to each one:

1. Use scoped keys: Stripe supports restricted keys, Cloudflare supports API tokens limited to specific zones and permissions, and most email services let you create send-only keys.
2. Use separate keys per site and environment: Staging and production should never share a key, so you can revoke one without affecting the other.
3. Avoid personal tokens for automation: Create a dedicated service account or deploy key instead of using a team member's personal access token.
4. Review third-party app access: Periodically check which apps are connected to your Google, Microsoft, GitHub, or Slack accounts and remove any you don't use.
5. Limit OAuth scopes: When a plugin asks for access to your Google account, check what it's requesting. Read-only analytics access is very different from full account access.

Applying Least Privilege to Servers

If you manage your own VPS or dedicated server:

• Don't log in as root: Create a personal user with sudo rights and disable root login over SSH.
• Use per-person SSH keys: Each person gets their own key in authorized_keys, so you can remove one without affecting others.
• Limit sudo: Not everyone needs full sudo. You can grant specific commands in a file under /etc/sudoers.d/, edited with visudo.
• Run services as unprivileged users: PHP-FPM pools, Node apps, and background workers should each run as their own non-root user.
• Restrict network access: Databases and caches like Redis should listen only on localhost or a private network, not the public internet.

For example, to allow a deploy user to reload PHP-FPM without full root access, you'd create /etc/sudoers.d/deploy using sudo visudo -f /etc/sudoers.d/deploy:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl reload php8.3-fpm

Adjust the PHP version to match your server. Always use visudo so syntax errors are caught before they lock you out of sudo.

Make Access Temporary

Least privilege isn't only about scope; it's also about time. Access that's no longer needed is pure risk.

• Set end dates for contractor access: Note the expected end date when you create the account, and remove it when the work finishes.
• Use temporary login tools: Plugins such as Temporary Login Without Password create WordPress logins that expire automatically.
• Review quarterly: Put a recurring reminder in your calendar to review users, keys, and connected apps.
• Offboard properly: When someone leaves, remove their accounts everywhere on your inventory, not just in the CMS.

Common Least Privilege Mistakes

• Everyone is an admin "just in case": This is the most common problem on small business sites.
• One shared login for the whole team: You can't remove one person or see who did what.
• Using the MySQL root user for WordPress.
• Giving plugins full access to your Google or social accounts without checking scopes.
• Forgetting about old staging sites: They often have weak passwords, old plugins, and access to production data.

---

FAQ: Principle of Least Privilege

---

Conclusion

The principle of least privilege is one of the most effective security ideas you can apply to a website, precisely because it doesn't depend on preventing every attack. It accepts that accounts get phished and plugins have bugs, and it makes sure that when they do, the damage stays small. Right-sized user roles, scoped database users, careful file ownership, restricted API keys, and non-root servers all work together to contain problems.

Start with the quickest win: review your CMS users and cut down the number of administrators. Then work outward to your hosting, database, keys, and servers. Build in regular reviews and make contractor access temporary by default. Over time, least privilege becomes a habit rather than a project, and your website becomes much harder to seriously damage.