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 WordPress 7.0.2 (latest stable). 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: the canonical security guide from the WordPress project.
- Brute Force Attacks: protecting the login and XML-RPC.
- 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:
<Files *.php>
Require all denied
</Files>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:
<Files wp-config.php>
Require all denied
</Files>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 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 plan, where this hardening and ongoing maintenance is handled for you.
