---
title: "WordPress Security Checklist"
description: "Harden your WordPress site on Noiz hosting with safe file permissions, wp-config.php settings, PHP execution blocks, request filtering and login protection."
url: "https://docs.noiz.ie/wordpress/wordpress-security-checklist/"
section: "WordPress"
categories:
- "Applications > WordPress > Security"
last_reviewed: "27 July 2026, against the current WordPress release"
---
# WordPress Security Checklist
WordPress powers a large share of the web, which makes it a constant target for automated attacks. The checklist below covers the hardening measures that matter most for a WordPress site running on Noiz hosting: locking down files, tightening the WordPress configuration, blocking dangerous requests, and protecting the login. Work through it whether you are securing a brand new install or auditing an existing site.
**Last reviewed:** 27 July 2026, against the current WordPress release. This guide is written for Noiz hosting and is kept current against WordPress. It complements, and does not replace, the official WordPress hardening documentation linked below.
### Official Documentation Reference
- [Hardening WordPress](https://wordpress.org/documentation/article/hardening-wordpress/): the canonical security guide from the WordPress project.
- [Brute Force Attacks](https://wordpress.org/documentation/article/brute-force-attacks/): protecting the login and XML-RPC.
- [FAQ: My Site Was Hacked](https://wordpress.org/documentation/article/faq-my-site-was-hacked/): what to do if a site is already compromised.
## Prerequisites
- Administrator access to the WordPress dashboard.
- Access to your site files, either through the File Manager in your Noiz control panel, SFTP, or SSH.
- A recent, verified backup. Several measures below (changing the table prefix, altering permissions, editing server config) can break a live site if applied carelessly, so always back up before you start.
Many of these measures can be applied automatically by the WordPress management tools built into your Noiz hosting control panel, and the rest can be applied by hand as described. If any step is unfamiliar, contact Noiz support before making the change on a production site.
## File and Directory Security
**Restrict file and directory permissions**
Overly permissive files can be read or altered by other processes on the server or by an attacker who gains a foothold. Set `wp-config.php` to `600`, other files to `644`, and directories to `755`. Never set anything to `777`.
**Disable directory browsing**
If directory listing is enabled, a visitor can open a folder that has no index file and see everything inside it, which reveals plugin names, versions, and file layout that attackers use to fingerprint your site. Directory browsing is off by default on most Noiz servers, but confirm it and disable it in your server configuration if needed. On Apache this is handled with an `Options -Indexes` directive in `.htaccess`. Note that custom directives already present in `.htaccess` can override this.
**Forbid PHP execution in wp-includes**
The `wp-includes` directory is not meant to serve PHP directly to visitors. Blocking PHP execution there stops an attacker who manages to drop a malicious file into it from running that file. This is applied through the server configuration (an `.htaccess` or nginx rule).
**Forbid PHP execution in wp-content/uploads**
The uploads directory holds media, not code. Preventing PHP execution there closes one of the most common ways a malicious upload becomes remote code execution. A simple `.htaccess` file inside `wp-content/uploads` does the job on Apache:
```
Require all denied
```
**Protect wp-config.php**
The `wp-config.php` file contains your database credentials and secret keys. If PHP processing is ever disabled on the server, its raw contents could be served as plain text. Block direct web access to it in your server configuration. On Apache:
```
Require all denied
```
**Disable PHP execution in cache directories**
If a compromised PHP file lands in a caching plugin's cache directory and can be executed, the whole site is at risk. Block PHP execution in cache directories. Be aware that a small number of poorly behaved plugins or themes store genuine PHP in their cache directory against WordPress guidance; if such a plugin stops working, you may need to relax this for that path only.
## WordPress Configuration Hardening
**Set strong security keys and salts**
WordPress uses a set of secret keys and salts (`AUTH_KEY`, `SECURE_AUTH_KEY`, `LOGGED_IN_KEY`, `NONCE_KEY` and their salt counterparts) to encrypt the information stored in login cookies. These should be long (60 characters or more), random, and unique to your site. Generate a fresh set from the official [WordPress salt generator](https://api.wordpress.org/secret-key/1.1/salt/) and paste them into `wp-config.php`. Rotating the keys immediately invalidates every existing login session, which is a useful first step if you suspect a session has been stolen.
**Disable the built-in file editor**
The dashboard's Theme and Plugin editors let anyone with administrator access edit live PHP straight from the browser. If an admin account is ever compromised, that is an instant path to injecting malicious code. Turn the editor off by adding this to `wp-config.php`:
```
define('DISALLOW_FILE_EDIT', true);
```
**Disable admin script concatenation**
WordPress bundles admin scripts together for speed, but the endpoint that does this has been abused in denial-of-service attacks. Disabling concatenation removes that vector. The trade-off is a small performance cost in the admin area only; visitors are unaffected. Add to `wp-config.php`:
```
define('CONCATENATE_SCRIPTS', false);
```
**Change the default database table prefix**
By default every WordPress install names its tables with the `wp_` prefix, which makes the database structure predictable and simplifies automated SQL injection. Using a different prefix removes that assumption. Changing the prefix on a site that already holds data is risky, so back up first and prefer setting a custom prefix at install time.
**Turn off pingbacks and XML-RPC abuse**
Pingbacks let other sites leave automatic comments when they link to your posts, but the same XML-RPC feature is routinely abused to launch distributed denial-of-service and brute-force attacks through your site. Disable XML-RPC pingbacks site-wide and turn off pingbacks on existing posts unless you have a specific reason to keep them.
**Disable unused scripting languages**
WordPress runs on PHP. Support for other scripting languages such as Perl or Python is not needed by the application, so switching it off in the server configuration removes an unnecessary attack surface.
## Access Control and Request Filtering
**Block access to sensitive files**
Certain files can expose connection credentials or reveal which known exploits apply to your site. Deny public access to configuration files, backups, and similar sensitive resources at the server level.
**Block access to potentially sensitive files**
Log files, shell scripts, and other executables sometimes end up in a site's directories. Denying public access to these file types prevents them from being read or run by an attacker.
**Block access to .htaccess and .htpasswd**
These files control server behaviour and can hold password hashes. If an attacker can read them, they gain a range of exploitation options. Web servers usually deny access to dot-files by default; confirm this is enforced on your site.
**Enable bot and brute-force protection**
Malicious bots scan sites for vulnerabilities and flood them with requests, driving up resource use. A bot protection or web application firewall layer blocks these before they reach WordPress. If you plan to run a legitimate security scanner against your own site, you may need to temporarily allow it, since scanners behave like bots.
## Login and Account Security
**Block author enumeration scans**
Attackers probe the `?author=` query and the REST API to discover valid usernames, then brute-force the passwords. Blocking author enumeration hides those usernames. Depending on your permalink setup, this can also affect author archive pages, so test that legitimate author listings still work.
**Avoid the default admin username**
A fresh install often creates an administrator called `admin`, which is the first username every brute-force tool tries. Create a new administrator account with a unique, non-obvious username, reassign any content owned by `admin` to it, and delete the `admin` account. Combine this with a strong, unique password and, ideally, two-factor authentication.
## Getting Help
Worked through methodically, this checklist closes off the great majority of automated WordPress attacks. Most of it is straightforward for a competent WordPress developer to apply and maintain as part of a routine maintenance plan.
If you are concerned about your site's security and do not have the time or the technical knowledge to attend to the above, reach out to Noiz support about moving your site onto a [Managed WordPress](https://www.noiz.co.za/wordpress.php) plan, where this hardening and ongoing maintenance is handled for you.
---
Source: https://docs.noiz.ie/wordpress/wordpress-security-checklist/