Tools

Comprehensive WordPress security tool

Tick the rules and the tool assembles a ready-to-use hardening configuration for WordPress: for an Apache / LiteSpeed server (the .htaccess file) or nginx, and separately for wp-config.php. It is one of the most effective ways to raise a site's security, because you block many attacks before PHP even runs. Rules that can break something are clearly marked with a risk label. Everything is computed in your browser, nothing is sent. This is a tool for administrators, so read the descriptions and test before deploying. Related: WordPress security.

Apache and LiteSpeed read the .htaccess file. nginx does not — you paste the rules into the server block.

.htaccess

Keys and salts

After an incident or taking over an old installation, rotate the keys in wp-config.php — this logs everyone out and invalidates stolen session cookies. You can use our salt keys generator.

Salt keys generator →

⚠ Before deploying to production, test the configuration on a staging environment and make a backup. A poorly chosen rule (IP restriction, HSTS, CSP) can lock out the panel or part of the site. The wp-includes rules are not suitable for Multisite without changes.

What hardening is and why it works at the server level

Hardening WordPress is a set of changes that reduce the attack surface without changing how the site looks and works for a visitor. The greatest value comes from rules enforced at the server level (Apache, LiteSpeed or nginx), because they act before a request even reaches PHP and WordPress. This makes them lightweight and effective against the mass, automated attacks that knock on every site every day. This generator assembles a ready-made set of such rules plus complementary constants in wp-config.php, in a proven, safe order. Treat it as a complementary layer, alongside updates, strong passwords, login protection and backups.

What makes a good security configuration

Protecting sensitive files Blocking network access to wp-config.php, dotfiles (.htaccess, .htpasswd), database dumps, logs and temporary files. This is the first and most important line of defense, because it protects the access credentials and configuration.

Blocking PHP execution in uploads The wp-content/uploads directory accepts files from users, so it is often a target for a webshell disguised as an image. Banning PHP execution in this directory neutralizes one of the most common site-takeover scenarios.

Limiting attack vectors Blocking xmlrpc.php (a frequent brute-force and DDoS amplification target), author enumeration (?author=ID) and the TRACE/TRACK methods limits reconnaissance and typical abuse techniques. We flagged some of these rules as risky, because they can conflict with plugins.

Security headers X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy limit clickjacking, data leaks and abuse in the browser. HSTS and Content-Security-Policy are the strongest but need careful deployment. More in our security headers generator.

Hardening wp-config.php Disabling the file editor in the dashboard (DISALLOW_FILE_EDIT), blocking unfiltered HTML, forcing HTTPS in the panel and automatic security patches close the configuration from the WordPress side. You can also assemble the snippets in the wp-config.php generator.

Apache/LiteSpeed vs nginx: where the rules go

Apache and LiteSpeed read the .htaccess file at the directory level, so you paste the rules into .htaccess in the WordPress root directory, above the # BEGIN WordPress block. nginx does not support .htaccess — the equivalent directives go into the server block of the configuration and you reload the server with nginx -t && systemctl reload nginx. The generator adjusts the syntax to the server you choose, and some rules (e.g. restricting wp-login.php to an IP in nginx) need to be adapted to your PHP-FPM configuration. The constants from the wp-config.php tab are server-independent and go into the wp-config.php file.

Author enumeration: one rule is not enough

The rule blocking ?author=ID closes the oldest way of discovering logins, but in modern WordPress there are two more vectors that .htaccess does not cover with this rule. The first is the REST API at /wp-json/wp/v2/users, which on many sites returns the list of authors together with their slugs (logins) without logging in. The second is the author map in the sitemap — since WordPress 5.5 at /wp-sitemap-users-1.xml — which also exposes account names. Fully closing the topic therefore additionally requires restricting the users endpoint in the REST API (usually with a PHP filter or a plugin) and removing authors from the sitemap. Enumeration itself is usually a low- or medium-severity issue, but it aids brute-force and phishing, so it is worth closing together with login protection.

Frequently asked questions about WordPress hardening

What is WordPress hardening?+

A set of changes that reduce the attack surface without changing how the site works: blocking access to sensitive files, disabling unnecessary features (xmlrpc, file editor), security headers and limiting attack vectors. It is a layer that complements updates, strong passwords and backups, not a replacement.

Where do I paste the generated rules?+

Rules for Apache and LiteSpeed into .htaccess in the root directory, above the # BEGIN WordPress block. For nginx into the server block (then nginx -t and reload). Constants from the wp-config.php tab into wp-config.php, above the "That's all, stop editing" line.

Can these rules break my site?+

Some can, which is why they are flagged with a "risk" label describing the consequences. Blocking xmlrpc breaks the mobile app and Jetpack, restricting wp-login.php to an IP can lock out the panel, and enable HSTS and FORCE_SSL_ADMIN only on stable HTTPS. Always test on a staging environment.

Do server-level rules replace a security plugin?+

They do not replace it, they complement it. Server rules act before a request reaches PHP, so they are lightweight and effective. A plugin adds monitoring, scanning and an application firewall. The best protection comes from combining both layers with updates and backups.

Does the generator send my data to a server?+

No. The configuration is assembled in your browser with JavaScript. The IP addresses, selected rules and settings you enter are never sent or stored anywhere beyond your device.

Tool and write-up: Marcin Szewczyk-Wilgan, WebOptimo. Rules based on the Apache, nginx and WordPress documentation and hands-on practice hardening and maintaining production WordPress installations. Test the generated configuration before deploying. The generator runs in your browser, with no data sent.

Contact

We'll secure your WordPress

We run security audits, hardening, hosting and server administration for WordPress and WooCommerce. No obligation — a concrete proposal after a short conversation.

Phone

+48 608 271 665

Mon–Fri, 8:00–16:00

E-mail

kontakt@weboptimo.pl

We reply within 24h

Company

WebOptimo

VAT ID: PL6391758393