WordPress Security Hardening: An Agency Grade Baseline

WordPress security hardening is best handled as layers: the host, a web application firewall, the WordPress application, user accounts and ongoing monitoring. No single plugin covers all five, and most compromises come from a gap in one layer, such as an outdated plugin, a reused password or an unmonitored admin account. The baseline below is the standard an agency should apply to every production site, with notes on what can be automated.

How to use this baseline

Treat each layer as a set of controls with an owner. Some controls are set once at launch; others need a schedule. The table summarises the layers before the detail.

The official WordPress hardening guide covers many of these controls and is worth reading alongside this checklist.

Layer one: host and server

Application hardening cannot compensate for a weak host. Start here.

Isolation and supported software

• Each site should run in its own isolated account or container, so a compromise on one site cannot spread to others on the same server.
• Run a PHP version that still receives security support, and keep the web server and database patched.
• Use HTTPS everywhere, with automatic certificate renewal.
• Disable directory listing and block direct web access to sensitive files such as wp-config.php, backups and logs.

File permissions

The WordPress guide advises locking file permissions down as much as possible: files should belong to your user account, and only the directories that genuinely need uploads or content changes should be writable by the web server. It gives the common pattern of 755 for directories and 644 for files, with wp-config.php restricted further. Your host's setup may differ, so confirm the right values with them rather than applying a blanket change.

Database

• Use a unique database user and strong password for each site.
• Limit the database user to the operations WordPress needs day to day. The official guide suggests restoring wider privileges temporarily only for updates that change the database structure.
• Never expose the database port to the public internet.

Backups

Back up files and the database on a schedule, store copies off the server, and keep several dates so you can recover from a compromise that went unnoticed for a while. A backup you have never restored is an assumption, so test a restore at least once a quarter.

Layer two: web application firewall and edge

A web application firewall inspects requests before they reach WordPress and blocks known attack patterns, such as SQL injection attempts, malicious uploads and requests targeting known plugin vulnerabilities.

Where to run it

• At the edge, through a CDN or reverse proxy service. Malicious traffic is filtered before it uses your server's resources. This is usually the strongest option.
• On the server, with a module such as ModSecurity, often provided by the host.
• Inside WordPress, through a security plugin. It understands WordPress context but runs only after PHP has started.

Many sites combine an edge firewall with a lighter WordPress security plugin for scanning and login protection. Avoid stacking several plugins that do the same job; they slow the site and conflict.

Rules worth adding

• Rate limit wp-login.php, XML-RPC and password reset requests.
• Block or challenge XML-RPC entirely if nothing on the site uses it.
• Challenge suspicious bot traffic on forms and checkout rather than on every page.
• Restrict wp-admin by IP address where your team works from known locations.

Layer three: the WordPress application

Updates

Many WordPress compromises exploit known vulnerabilities in plugins and themes for which fixes are already available. Keep core, plugins and themes updated, and remove anything inactive. WordPress supports automatic updates for core and for individual plugins and themes; enable them for low risk components and route larger updates through staging first.

Configuration hardening

• Disable the file editor. Adding DISALLOW_FILE_EDIT to wp-config.php removes the dashboard editor for theme and plugin code. The official guide notes this will not stop every attack, but it removes an easy route for anyone who gains admin access.
• Set unique keys and salts in wp-config.php, and rotate them after any suspected breach to sign out every session.
• Turn off debug output on production so errors do not reveal paths and versions.
• Block PHP execution in uploads. The uploads folder should hold media, not scripts.

Plugin and theme governance

Every plugin is code from another party running with full access to your site. Keep an approved list, install only from reputable sources with recent updates and active support, and review the list each quarter. Our guide to lean WordPress plugin governance sets out a review process. Never use nulled or pirated premium plugins; they are a common source of hidden malware.

Layer four: accounts and login protection

Login protection matters because stolen or guessed credentials remain one of the simplest ways into a site.

Login protection controls

• Two factor authentication for every account with editor rights or above, and ideally for all staff accounts.
• Strong unique passwords stored in a password manager, never shared between people.
• Login throttling and temporary lockouts after repeated failures.
• No obvious usernames. Avoid "admin" and avoid usernames that match public author names.

Roles and access

• Give each person the lowest role that lets them do their job. Most content staff need Editor or Author, not Administrator.
• Create named accounts for agencies and freelancers, and remove them when the work ends.
• Review all administrator accounts monthly; an unknown admin account is a common sign of compromise.

API access and integrations

Since WordPress 5.6, Application Passwords let integrations call the REST API without using a person's main password, and they cannot be used to log in to the dashboard, according to the WordPress core integration guide. Give each integration its own application password on a dedicated low privilege account, and revoke it when the integration is retired.

Layer five: monitoring and response

What to monitor

• Uptime and response checks on key pages and forms.
• File integrity: alerts when core files change or new PHP files appear.
• Login activity, new users and role changes.
• Web server access and error logs, retained long enough to investigate an incident.
• Malware and blocklist checks for the domain.

An incident plan on one page

1. Who decides to take the site offline or into maintenance mode.
2. Where clean backups are and how to restore them.
3. How to rotate passwords, keys, salts and API credentials.
4. Who contacts the host, payment provider and, where personal data may be affected, legal counsel.

Hypothetical example: a services company in Abu Dhabi finds a new administrator account it did not create. Following its plan, it puts the site into maintenance mode, removes the account, restores files from a clean backup, updates the vulnerable plugin that was exploited, rotates all credentials and salts, and reviews the logs to see whether form submissions were accessed.

A WordPress security checklist for launch day

When a new site goes live, or an existing one is handed over to a new team, run through this short list before calling the work finished:

• Every administrator account is named, necessary and protected with two factor authentication.
• Default and test content, unused themes and inactive plugins are removed.
• DISALLOW_FILE_EDIT is set and debug output is off.
• The firewall is active, and login and XML-RPC rate limits are in place.
• Backups run on schedule, are stored off the server, and one restore has been tested.
• Uptime, file change and login alerts reach a monitored inbox, not a former employee.
• Staging exists, is protected from public access and is excluded from search engines.
• The incident plan names an owner and lists where credentials are stored.

Record the result with a date. When something changes later, such as a new plugin, a new integration or a new hosting plan, rerun the list rather than assuming the original baseline still holds.

Privacy and the UAE context

Many WordPress sites collect personal data through contact forms, bookings and newsletter sign ups. The UAE Personal Data Protection Law, Federal Decree-Law No. 45 of 2021, sets general rules for processing personal data, and the DIFC and ADGM have their own data protection regimes. Healthcare providers may also be subject to rules from the Dubai Health Authority or the Department of Health Abu Dhabi. Hardening is one part of meeting these obligations; confirm what applies to your organisation with legal counsel or the relevant regulator.

If you run more than one platform, our security checklist for WordPress, Django and Strapi applies the same thinking across stacks, and WordPress or Strapi compares the two for multi channel content. Online stores should add the controls in our WooCommerce performance and security checklist, and security changes should be checked against speed using the WordPress speed checklist.

Putting a security baseline in place with Codeeo

Codeeo's WordPress development team applies hardening as part of builds and ongoing work, from host configuration and firewall rules to roles, updates and monitoring. If you are unsure where your current site stands, a website audit is a practical starting point, and we work with healthcare and other organisations that handle sensitive enquiries. UAE clients can meet the team at our Dubai office. Contact Codeeo to discuss your site.