WordPress security and development for working teams

11 November 2026

Keeping WordPress core, plugins and themes up to date is the single most important security measure, according to the [WordPress Advanced Administration Handbook](https://developer.wordpress.org/advanced-administration/security/). Everything else a team does, from permissions to code review, works around that baseline rather than replacing it. A site that is perfectly configured but runs an abandoned plugin is still exposed, and a fully patched site with sloppy accounts is exposed in a different way.

Security is a routine, not a project

The same handbook describes WordPress security as two layers. Environment-level controls cover the server and its settings, such as file permissions. Application-level controls cover what happens inside WordPress itself, such as user roles. A working team needs somebody responsible for each layer, and in practice the gap tends to appear between them: the host assumes the agency manages plugins, and the agency assumes the host manages the server.

Wordfence's 2024 Annual WordPress Security Report points the same way. It recommends keeping plugins and themes current and using automated or semi-automated patch management. The reasoning is operational. If patching depends on someone remembering to log in on a quiet afternoon, it will slip during a product launch or a holiday week. Putting updates on a schedule, with a named owner and a way to test them first, turns patching from a favour into a process.

WP VIP, which works with large organisations, makes a related point about enterprise sites: no single security plugin solves the problem. Security requires the ongoing application of best practices. For a small team the lesson holds at any scale. Installing one well-reviewed tool and moving on creates a feeling of safety that the site has not earned. The remaining sections follow the order a team would normally work in: who has access, how the environment is locked down, how code is written, and how the site is watched and recovered.

Access control, roles and team responsibilities

Most teams that run WordPress have more people touching it than they realise. Editors publish, developers deploy, a marketing contractor installs a plugin for a campaign, and a vendor keeps an admin login from a project that ended last year. WP VIP says enterprise security needs role-based access control so that permissions stay aligned with team roles and responsibilities. The point is not bureaucracy. It is that every account should be able to do the job attached to it and little else.

WordPress ships with built-in user roles, and the handbook treats them as part of application-level security. In practice that means an editor does not need administrator rights to fix a headline, and a freelance writer does not need access to plugin settings. When an account is compromised, whether through a reused password or a phished login, the damage is bounded by what that account could do. An attacker who lands in a contributor account has a much harder time than one who lands in an administrator account.

A few habits make role assignments hold up over time. Review the user list on a regular schedule and remove accounts belonging to people who have left the team or finished a contract. Give vendors accounts of their own rather than a shared login, so that activity can be traced to a person. Raise permissions for a specific task and lower them afterwards, instead of leaving elevated access in place "just in case".

The stakes rise with the kind of site involved. A team maintaining the content layer for in-play betting platforms accepting M-Pesa deposits in Kenya, for example, would want a sharp line between the people who write and publish pages and the people who can install code or change settings, because a mistake or a stolen login in the second group reaches much further. The same separation helps a newsroom, a shop or a school site, only with less at risk when it fails.

Hardening the WordPress environment

Hardening is the environment-level half of the picture. The WordPress Hardening handbook advises locking down file permissions as much as possible and loosening them only when write access is genuinely needed. That wording matters: the default stance is restrictive, and exceptions are deliberate and temporary. A common mistake is to open permissions broadly to get an upload or an update working, then never close them again.

Rainforest's 2026 WordPress hardening guide adds several concrete steps that most teams can apply without rebuilding anything. They are small individually, but together they remove the easy routes an attacker would otherwise try first. Here are the measures the two sources describe:

• File permissions: set them correctly, keep them as restrictive as possible, and open write access only where it is needed.
• wp-admin: restrict access to the admin area rather than leaving it open to anyone who finds the login page.
• xmlrpc.php: disable it if the site does not use it.
• Dashboard file editing: turn off the built-in theme and plugin editor so that code cannot be changed from inside WordPress.

Each item deserves a quick check before it is switched. Some mobile apps and remote publishing tools rely on xmlrpc.php, so confirm that nothing in the workflow depends on it first. Restricting wp-admin by location or login method can lock out a remote editor if nobody has told them, so tell the team before the change goes live. Disabling the dashboard editor is the least disruptive of the four, and it closes a path where a single compromised administrator account could edit live code directly. Because these settings live in server and configuration files, record them somewhere the whole team can find, so a site migration or a new host does not quietly undo them.

Secure development and coding practices

Teams that write their own themes and plugins carry a responsibility that no hardening checklist can discharge. The WordPress Common APIs Handbook is direct about it: developers should validate and sanitize user input before using it, and escape output. Those three verbs describe a sequence. Check that incoming data is what you expect, clean it before it is stored or processed, and make it safe at the moment it is printed to a page.

Skipping any step tends to produce the same family of problems, where text typed into a form or passed in a URL ends up being treated as code. The cause is rarely exotic. It is usually a custom field, a search box or a small shortcode written quickly and never revisited. Because the handbook's advice applies to anything that crosses a boundary between a user and the site, it is worth treating every such boundary as untrusted by default, including data from logged-in users and from internal tools.

Process helps where individual discipline gives out. Have a second developer read every change before it is deployed, and make "where does this input come from, and where does this output go?" a standing question in that review. Keep custom code in version control so that changes are visible and reversible. Test updates and new code on a staging copy first, so that a fault shows up there rather than in front of readers or customers.

Third-party code deserves the same suspicion. A plugin installed for a single feature becomes part of the site's attack surface, which is why the update advice from the first section applies to it equally. Before adding one, ask whether the feature is really needed, whether the plugin is still maintained, and who on the team will own its updates. Removing what is no longer used is one of the cheapest security improvements available.

Monitoring, scanning and recovery

Prevention reduces risk but cannot remove it, so the last layer assumes something will eventually get through. Wordfence's 2024 report recommends using a Web Application Firewall and a malware scanner as layered defences, alongside the patching discipline described earlier. The firewall works at the front door by filtering suspicious requests before they reach WordPress. The scanner works after the fact by looking for changed files and known malicious code. Neither replaces the other, and neither replaces a patched site.

This is what WP VIP means by ongoing application of best practices. Monitoring only helps if somebody reads the output. Decide who receives scanner alerts, what counts as urgent, and what that person does at midnight on a weekend. A report that lands in an unwatched inbox offers no more protection than having no scanner at all. Schedule regular operational checks as well: confirm that updates have been applied, that the user list still matches the team, and that the hardening settings from earlier are still in place.

Recovery planning is the part teams most often leave until they need it. Keep backups that are stored away from the web server and that someone has actually restored, because an untested backup is only a hope. Write down the first steps for a suspected compromise: who is told, which accounts have their passwords reset, and when the site is taken offline. After an incident, work out how the attacker got in and close that route, rather than simply restoring and carrying on.

Finally, if anyone on the team believes they have found a vulnerability in WordPress itself, [WordPress.org](https://wordpress.org/about/security/) asks that it be kept confidential and reported to the WordPress Security Team. Publicising it first, even in a team chat that spills into a public forum, hands attackers a head start. Put that instruction into the team's incident notes so it is on hand when the moment comes.