The ‘No-Plugin’ WordPress Security Guide: Complete Manual Hardening for 2026

Why Choose a No-Plugin Approach to WordPress Security?

In an ecosystem dominated by “all-in-one” security suites, the idea of securing a WordPress site manually might seem counterintuitive. However, for 2026, the “No-Plugin” philosophy is gaining traction among senior developers and performance-obsessed site owners. It shifts the defense perimeter from the application layer (PHP) to the server layer (Apache/Nginx/Firewall), creating a faster, leaner, and often more secure environment.

The Hidden Cost of Security Plugins: Performance and Bloat

Security plugins often act as a firewall after the request has already hit your server and initialised WordPress. This means that every time a bot scans your site, the security plugin fires up PHP, queries the database to check blocklists, and consumes memory.

On a high-traffic site, this “security overhead” can increase Time to First Byte (TTFB) by 200–500ms. By handling security at the server level (e.g., via .htaccess or Cloudflare), you block threats before WordPress even wakes up, preserving resources for legitimate users.

The Database Bloat Problem (The Wordfence Effect) Beyond CPU usage, popular plugins like Wordfence are notorious for creating massive database tables that can cripple your site’s performance.

• Live Traffic Logging: To show you “who is visiting right now,” the plugin writes every single hit to your database. We frequently see the wp_wfhoover and wp_wfhits tables grow to multiple gigabytes in size.
• The Consequence: A 2GB database takes significantly longer to backup and query than a 200MB one. This bloat can lead to “Error Establishing Database Connection” timeouts during traffic spikes, effectively doing the hacker’s job for them (taking your site offline).

Read: wp_wfhoover table is massive

Plugins as Attack Vectors: The Irony of Security Software

It is a bitter irony that security plugins themselves can introduce vulnerabilities. In recent years, critical privilege escalation and XSS flaws have been discovered in major security suites. By relying on a plugin, you add thousands of lines of third-party code to your site. A manual approach reduces this “attack surface” significantly. If the code isn’t there, it cannot be exploited.

Benefits of Manual Security: Control, Speed, and Reliability

• Zero Latency: Rules implemented in .htaccess or Nginx config execute in milliseconds.
• Total Control: You know exactly every rule protecting your site. There are no “black box” settings.
• Unhackable Logic: A plugin can be deactivated if a hacker gains admin access. Hard-coded server rules are much harder to bypass from within the WordPress dashboard.

Who This Guide Is For: Skill Level and Requirements

This guide is written for intermediate to advanced WordPress users. You should be comfortable with:

• Using an FTP/SFTP client (like FileZilla).
• Editing raw code files (.php, .htaccess).
• Accessing your hosting control panel (cPanel, Plesk, or Terminal).

Warning: Manual hardening involves editing core configuration files. A misplaced character can take your site offline. Always backup before editing.

Understanding WordPress Vulnerabilities Without Plugin Dependency

To defend your site manually, you must think like an attacker. Most WordPress hacks in 2026 follow predictable patterns that do not require an expensive scanner to understand.

How WordPress Sites Get Hacked: Common Attack Vectors

90% of infections stem from three sources: compromised credentials, outdated software, or insecure hosting environments. Automated botnets scour the web 24/7 looking for specific “fingerprints” of vulnerable sites.

Brute Force Attacks and Credential Stuffing

Bots target /wp-login.php with millions of username/password combinations. They don’t just guess “password123”; they use databases of leaked credentials from other breaches (credential stuffing).

SQL Injection and Cross-Site Scripting (XSS)

• SQLi: Attackers trick the database into revealing sensitive data (like user passwords) via poorly sanitized input fields.
• XSS: Attackers inject malicious scripts into pages viewed by other users (often administrators), stealing their session cookies.

Backdoors, Malware, and Pharma Hacks

Once inside, hackers install “backdoors” (hidden PHP files) to ensure they can return even if you change passwords. These are often used for “Pharma Hacks,” where your site displays ads for illicit drugs only to search engine crawlers (SEO spam).

XML-RPC Exploits and DDoS Amplification

The xmlrpc.php file is a legacy API often used to launch Distributed Denial of Service (DDoS) attacks. Attackers use your site as a weapon to attack others, or flood your site with requests to exhaust your server’s memory.

Essential Preparations Before Implementing The ‘No-Plugin’ WordPress Security Guide

Before touching a single line of code, you must secure your escape route.

Creating a Complete Manual Backup (Files and Database)

Do not rely on your host’s automated backups alone. You need a portable snapshot of your site.

Backing Up WordPress Files via FTP/SFTP

1. Connect to your server using an FTP client.
2. Navigate to your public_html directory.
3. Download the entire folder to your local computer. Ensure you capture hidden files (like .htaccess) by enabling “Force showing hidden files” in your FTP client options.

Exporting Your Database via phpMyAdmin

1. Log in to your hosting control panel and open phpMyAdmin.
2. Select your WordPress database.
3. Click the Export tab.
4. Choose Quick method and SQL format.
5. Click Go to download the .sql file.

Setting Up Automated Server-Side Backups via Cron

For ongoing protection without plugins, use a server-side shell script.

(Note: Requires SSH access)

Bash

# Example Cron job to zip site and dump DB every night at 3 AM
0 3 * * * tar -zcf /backups/site-$(date +\%F).tar.gz /var/www/html && mysqldump -u [user] -p[password] [db_name] > /backups/db-$(date +\%F).sql

Accessing and Editing Critical Files Safely

Never edit files via the WordPress Dashboard (Appearance > Theme Editor). If you make a syntax error there, the “White Screen of Death” will lock you out. Always edit locally using a code editor (VS Code, Sublime Text) and upload via FTP.

Understanding .htaccess, wp-config.php, and functions.php

• .htaccess: The gatekeeper. Controls how the server handles requests before they reach WordPress.
• wp-config.php: The brain. Controls database connections and global settings.
• functions.php: The nervous system. Adds features and hooks to your specific theme.

Securing WordPress Core: Updates and Version Management

Why Updates Are Your First Line of Defense

Vulnerabilities are often patched by developers within hours of discovery. If you are running WordPress 6.2 when 6.6 is out, you are vulnerable to every exploit discovered in the gap.

Enabling Automatic Core Updates via wp-config.php

Force WordPress to apply security patches automatically by adding this to wp-config.php:

PHP

define( 'WP_AUTO_UPDATE_CORE', true ); // Major and minor updates
// OR
define( 'WP_AUTO_UPDATE_CORE', 'minor' ); // Only security fixes (Recommended)

Managing Theme and Plugin Updates Without Automation Tools

Without a plugin manager, you must establish a routine. Check your WordPress Maintenance schedule weekly. Use the dashboard’s “Updates” tab, or if you manage multiple sites, script updates via WP-CLI: wp plugin update --all.

Removing the WordPress Version Number from Source Code

Broadcasting your version number tells hackers exactly which exploits will work. Remove it by adding this to your theme’s functions.php:

PHP

// Remove version from head and feeds
function remove_version_info() {
    return '';
}
add_filter('the_generator', 'remove_version_info');

Hardening wp-config.php: Your Security Command Center

The wp-config.php file contains your database name, username, and password. If a hacker can read this file, they own your site. Unlike plugins that try to block attacks at the front door, hardening this file locks the vault itself.

Moving wp-config.php Above the Web Root

By default, WordPress lives in a folder often called public_html (or www). If your server is misconfigured, it might accidentally serve .php files as text, allowing anyone to download your config file and see your passwords.

The fix is simple: Move the file out of the public folder.

How it works: WordPress is smart. It automatically looks one directory up from its installation folder to find wp-config.php.

Step-by-Step:

1. Connect to your site via FTP (FileZilla) or your hosting File Manager.
2. Locate wp-config.php inside the public_html folder.
3. Drag and drop it one level up (into the /home/username/ folder).
4. Result: Your site still loads perfectly, but the file is now inaccessible via a web browser (yoursite.com/wp-config.php will trigger a 404 error).

Note: This method works on most standard Linux hosting environments (cPanel/Bash). It may not work on some specialized managed hosting platforms that lock directory permissions.

Generating and Implementing Unique Security Keys and Salts

Inside wp-config.php, you will see a block of code labeled “Authentication Unique Keys and Salts.” These are random strings used to encrypt the cookies stored in your browser.

Why update them? If you suspect your site has been hacked, or if you just took over a site from another developer, changing these keys instantly invalidates all login cookies. This forces every user (including potential hackers) to log in again.

Do not make these up yourself. Use the official API.

1. Visit: https://api.wordpress.org/secret-key/1.1/salt/
2. Copy the entire block.
3. Paste it over the existing block in your config file.

PHP

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

Disabling File Editing in the WordPress Dashboard

By default, an administrator can edit theme and plugin code directly from the WordPress Dashboard (Appearance > Theme File Editor).

This is a massive security risk. If a hacker guesses your password, they can use this editor to inject malware or a “backdoor” into your theme’s functions.php file instantly. Disabling this feature blocks that attack vector entirely.

PHP

define( 'DISALLOW_FILE_EDIT', true );

Forcing SSL for Admin and Logins

Even if you have an SSL certificate installed, WordPress might sometimes load the admin dashboard over HTTP. This sends your password in plain text across the network. This snippet forces the entire dashboard to run over a secure HTTPS connection.

PHP

define( 'FORCE_SSL_ADMIN', true );

Disabling WP_DEBUG on Production Sites

Developers often turn on WP_DEBUG to find errors. However, leaving it on can display sensitive server paths and error messages to visitors (and hackers) on the front end. On a live site, this should always be false.

PHP

define( 'WP_DEBUG', false );
// Hide errors from the screen
define( 'WP_DEBUG_DISPLAY', false );
// Prevents WordPress from running via script
define( 'SCRIPT_DEBUG', false );

Limiting Post Revisions and Autosave Intervals

While not strictly a “security” hack, this prevents Database Denial of Service (DoS) attacks where the database bloats until the server crashes. By limiting the number of revisions WordPress saves, you keep the database lean and responsive.

PHP

// Limit to the last 5 revisions per post
define( 'WP_POST_REVISIONS', 5 );
// Increase autosave interval to 300 seconds (5 minutes)
define( 'AUTOSAVE_INTERVAL', 300 );

Complete wp-config.php Security Code Snippet

Here is the aggregated code block. You can paste this into your wp-config.php file, just above the line that says /* That's all, stop editing! Happy publishing. */.

PHP

/**
 * NO-PLUGIN SECURITY HARDENING
 * Added by [Your Name/Agency]
 */

// 1. Disable the Theme/Plugin Editor to prevent code injection
define( 'DISALLOW_FILE_EDIT', true );

// 2. Force SSL for Admin Dashboard
define( 'FORCE_SSL_ADMIN', true );

// 3. Disable Debugging to hide server paths
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

// 4. Block external requests (Optional - advanced hardening)
// define( 'WP_HTTP_BLOCK_EXTERNAL', true );

// 5. Database Performance Protection
define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 300 );

Mastering .htaccess Security Rules (Apache Servers)

The .htaccess (Hypertext Access) file is a configuration file used by the Apache web server. Think of it as the “bouncer” at the club. It stands outside the door and checks everyone’s ID before they are allowed inside to talk to WordPress.

Because these rules execute at the server level, they are significantly faster than any security plugin. A plugin has to load PHP and connect to the database to block an IP. The .htaccess file blocks them instantly, saving your server resources.

Warning: This file is extremely sensitive. A single missing character or misplaced space can take your site offline (Internal Server Error 500). Always backup your current .htaccess file before making changes.

Protecting wp-config.php from Direct Access

As discussed earlier, wp-config.php holds your database keys. Even if you haven’t moved it above the root directory, you can block web access to it completely.

Apache

<files wp-config.php>
order allow,deny
deny from all
</files>

Blocking Access to .htaccess Itself

Ideally, no one should be able to view your security rules to see how you are protecting the site. This snippet ensures that if someone tries to load yoursite.com/.htaccess in a browser, they get a 403 Forbidden error.

Apache

<files ~ "^.*\.([Hh][Tt][Aa])">
order allow,deny
deny from all
satisfy all
</files>

Disabling Directory Browsing and Indexing

If you create a folder called /my-files/ but don’t put an index.php file inside it, Apache’s default behaviour is to list every single file in that directory. This is a gift to hackers doing reconnaissance (“recon”), as it lets them see exactly what plugins, themes, and versions you have installed.

Apache

Options -Indexes

Preventing PHP Execution in wp-content/uploads

This is perhaps the most critical rule in this entire section. Hackers often gain access by uploading a malicious file (like a backdoor shell) via a contact form or a vulnerability in an image upload plugin. They disguise the file as image.jpg but it actually contains PHP code.

To stop this, we tell the server: “Never execute any PHP scripts inside the uploads folder.”

Instruction: You need to create a new, separate .htaccess file, paste the code below inside it, and upload it specifically to the /wp-content/uploads/ folder.

Apache

<Files *.php>
deny from all
</Files>

Blocking Malicious Query Strings and Request Methods

This rule replaces the core functionality of many “Web Application Firewall” (WAF) plugins. It looks for common patterns used in SQL Injection (SQLi) and Cross-Site Scripting (XSS) attacks, such as attempts to inject <script> tags or modify global variables via the URL.

Apache

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ - [F,L]
</IfModule>

Restricting Access to wp-includes

The /wp-includes/ folder contains the core logic of WordPress. Regular visitors never need to access files in this folder directly; only WordPress itself needs to access them internally. Blocking direct access here breaks many automated exploit bots.

Apache

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

IP Whitelisting for wp-admin Access

If you have a static IP address (e.g., from your office or home internet provider), you can lock down your admin area so that only your computer can access it.

The Risk: If your internet provider changes your IP (dynamic IP) or you try to log in from a cafe, you will be locked out. Use this only if you are sure about your network setup.

Apache

<Files wp-login.php>
order deny,allow
Deny from all
# Replace with your IP address
Allow from 123.456.789.000
</Files>

Complete .htaccess Security Template

Here is a consolidated block containing the safest, most compatible rules from above. You can paste this at the top of your main .htaccess file, before the # BEGIN WordPress line.

Apache

# --- START NO-PLUGIN SECURITY HARDENING ---

# 1. Protect Config file
<files wp-config.php>
order allow,deny
deny from all
</files>

# 2. Protect .htaccess file
<files ~ "^.*\.([Hh][Tt][Aa])">
order allow,deny
deny from all
satisfy all
</files>

# 3. Disable Directory Browsing
Options -Indexes

# 4. Block Malicious URL Characters (Basic WAF)
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ - [F,L]
</IfModule>

# --- END NO-PLUGIN SECURITY HARDENING ---

Nginx Security Configuration (For Non-Apache Servers)

If your site is hosted on a high-performance VPS or a managed WordPress host, you likely aren’t using Apache. Therefore, the .htaccess rules above will do absolutely nothing. You need to edit the nginx.conf server block.

Note: Unlike .htaccess, editing Nginx configuration usually requires root access (SSH) to the server. If you are on shared hosting using Nginx, you may need to ask your support team to add these rules for you.

Blocking Sensitive Files and Directories

Just like with Apache, we must ensure no one can download your wp-config.php or view your hidden files.

Nginx

location ~* /wp-config.php {
    deny all;
}
location ~* /\.ht {
    deny all;
}

Rate Limiting and Connection Restrictions (Brute Force Protection)

Nginx has a powerful built-in module for rate limiting. This is far superior to any plugin because it drops the connection before PHP even wakes up.

Step 1: Define the Limit Zone (Add this to the http block in your main nginx.conf file, outside the server block).

Nginx

# Store IP addresses in a 10MB zone (holds ~160k IPs)
# Limit to 1 request per second (1r/s)
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

Step 2: Apply the Limit to Login Page (Add this inside your site’s server block).

Nginx

location = /wp-login.php {
    # Allow a 'burst' of 1 extra request, then reject.
    limit_req zone=one burst=1 nodelay;
    
    # Pass to PHP backend (adjust socket path as needed)
    include fastcgi_params;
    fastcgi_pass unix:/var/run/php/php8.4-fpm.sock; 
}

What this does: If a bot tries to hit your login page 5 times in a second, Nginx will serve the first one and immediately drop the other 4 with a “503 Service Unavailable” error. The bot never gets a chance to guess passwords.

Preventing PHP Execution in Uploads

Stop hackers from running malicious scripts they managed to upload.

Nginx

location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
}

Applying the Changes

After saving your configuration file, you must test and reload Nginx for the changes to take effect.

• Reload: sudo systemctl reload nginx.
• Test syntax: sudo nginx -t (If you see “successful”, proceed).

Login and Authentication Hardening Without Plugins

The login screen is the front door to your website. Most hacks occur here because it is the only place where a bot can enter a password to gain control. Here is how to reinforce that door using manual methods.

Changing the Default ‘admin’ Username via Database

If your username is “admin,” you have already lost 50% of the battle. Hackers only need to guess your password. Since you cannot change usernames easily in the dashboard, do it via the database.

1. Log in to phpMyAdmin via your hosting panel.
2. Open the wp_users table.
3. Click Edit next to the admin user.
4. Change the user_login field to something unique (e.g., J_Song_88).
5. Crucial: Check the wp_usermeta table. Search for any rows where meta_value contains “admin” (often the nickname or user_level) and update them to match your new username.

Enforcing Strong Passwords with functions.php

You cannot force users to use strong passwords without a plugin, but you can nag them. However, for a “No-Plugin” site, the best enforcement is administrative policy: simply do not create accounts for users with weak passwords.

Changing the WordPress Login URL Manually (And Why It Is Not Enough)

A common piece of advice is to “hide” your login page by renaming /wp-login.php to something custom, like /my-secret-entry.

How to do it manually (Apache): Add this line to your .htaccess file:

Apache

RewriteRule ^my-secret-entry$ http://yoursite.com/wp-login.php [NC,L]

Now, visiting yoursite.com/my-secret-entry redirects you to the login page.

Why Changing Your Login URL is (Mostly) Useless

Sophisticated bots do not care what you renamed your login page to for three key reasons:

1. The “Side Door” Attack (XML-RPC) Modern brute force attacks rarely use the visual login form. Instead, they target a file called xmlrpc.php, which acts as a remote control for your website. A hacker can send a single HTTP request containing 500 different username/password combinations to xmlrpc.php. The server processes them all instantly, completely bypassing your renamed login URL.
2. The “Redirect” Leak WordPress is sometimes too helpful. If a bot tries to visit /wp-admin/ (which you likely didn’t rename), WordPress often automatically redirects them to your new custom login URL. You have effectively handed the intruder the key to the hidden door.
3. The REST API Endpoint Attackers can use the wp-json/jwt-auth/v1/token endpoint (if enabled) or other API routes to validate credentials, again bypassing the visual login form entirely.

The Solution: Don’t Hide It, Lock It Instead of relying on “Security through Obscurity” (hiding the URL), use Basic Authentication (see below) or IP Whitelisting. This blocks the connection at the server level, regardless of which URL the attacker tries to hit.

Implementing Two-Factor Authentication Without a Plugin (Basic Auth)

True “No-Plugin” 2FA uses the server’s native authentication. This adds a browser-level popup requesting a username and password before the WordPress login screen even loads. If the bot doesn’t know this server password, they cannot touch WordPress.

Step 1: Create a Password File Use an online “htpasswd generator” to create a user (e.g., frontdoor) and a password. Paste the result into a new text file named .htpasswd. Upload this file to a folder above your public web root (e.g., /home/username/.htpasswd) so it cannot be downloaded.

Step 2: Update .htaccess Add this code to your .htaccess file:

Apache

# Protect wp-login.php
<Files wp-login.php>
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/username/.htpasswd
require valid-user
</Files>

Limiting Login Attempts via functions.php

While robust rate-limiting is best handled by Nginx or a firewall (as detailed in previous sections), you can add a simple timestamp check to PHP as a fallback. (Note: For a purely manual setup, we strongly recommend using the Nginx rate-limiting or Basic Auth method above, as PHP-based limiting can still consume server resources under heavy attack.)

Automatically Logging Out Idle Users

If a user leaves their computer unlocked, their session remains open. Force a logout after a set time by adding this to your theme’s functions.php:

PHP

function auto_logout_idle_user($expiration, $user_id) {
    return 1800; // 30 minutes in seconds
}
add_filter('auth_cookie_expiration', 'auto_logout_idle_user', 10, 2);

Preventing User Enumeration Attacks

Hackers often type /?author=1 into the browser to reveal your admin username. Block this request using .htaccess:

Apache

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} ^author=([0-9]*) [NC]
RewriteRule .* http://yoursite.com/? [L,R=302]
</IfModule>

Disabling Dangerous WordPress Features

WordPress comes with several features enabled by default that were useful in 2010 but are liabilities in 2026. Specifically, XML-RPC and unrestricted REST API access are the two most common vectors for automated attacks.

Completely Disabling XML-RPC via .htaccess

xmlrpc.php is a legacy API that allowed external apps (like Windows Live Writer) to publish content. Today, it is primarily used by botnets to launch DDoS attacks or brute force your login.

If you do not use the WordPress Mobile App or Jetpack, you should kill this file immediately.

The Code (Apache): Add this to your .htaccess file:

Apache

<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Result: Any bot trying to hit xmlrpc.php gets a 403 Forbidden error instantly.

Disabling XML-RPC via functions.php Filter

If you cannot edit your server config, or if you want a softer disable that can be toggled via theme code, use this filter in your theme’s functions.php.

PHP

add_filter( 'xmlrpc_enabled', '__return_false' );

Note: This stops the function from working, but the server still loads WordPress to process the request. The .htaccess method is superior for performance.

Restricting the WordPress REST API

The REST API (/wp-json/) is powerful, but by default, it allows anyone to query your site’s data. Attackers use it to list all your users, view public posts, and scrape data.

Warning: Do not disable the REST API completely. The WordPress Block Editor (Gutenberg) relies on it. If you disable it entirely, you will break your ability to write posts.

The Solution: Restrict the API so it is only available to logged-in users. Add this to your functions.php:

PHP

add_filter( 'rest_authentication_errors', function( $result ) {
    if ( ! empty( $result ) ) {
        return $result;
    }
    if ( ! is_user_logged_in() ) {
        return new WP_Error( 'rest_not_logged_in', 'You are not currently logged in.', array( 'status' => 401 ) );
    }
    return $result;
});

Now, the Block Editor still works (because you are logged in), but external bots get a 401 Unauthorized error.

Disabling Pingbacks and Trackbacks

Pingbacks were designed to notify you when another blog linked to you. Today, 99% of them are spam or used for DDoS attacks (using your site to ping others).

How to disable:

1. Go to Settings > Discussion in your dashboard.
2. Uncheck “Allow link notifications from other blogs (pingbacks and trackbacks) on new posts.”
3. Note: This only applies to new posts. To disable it on old posts, you may need to run a database query or bulk edit your posts.

Turning Off User Registration (If Not Needed)

If you run a blog or business site that doesn’t require customers to create accounts, ensure the registration gate is closed. Hackers often create thousands of “Subscriber” accounts to bloat your database or try to escalate privileges.

How to disable:

• Go to Settings > General.
• Uncheck “Anyone can register.”

Database Security and Hardening

If the file system is the body of your WordPress site, the database is the brain. It holds every post, comment, user password, and setting. A successful SQL Injection (SQLi) attack here can give a hacker complete control without them ever needing to log in.

Changing the Default WordPress Table Prefix

By default, WordPress assigns the prefix wp_ to every table in your database (e.g., wp_users, wp_posts). This predictability is a gift to hackers.

If an attacker finds a vulnerability in a plugin that allows them to run SQL commands, they will blindly target wp_users to steal passwords. If you change the prefix to something random, their blind attacks will fail because the table wp_users does not exist.

Scenario B: Existing Sites (Advanced) Warning: This operation carries a high risk of breaking your site if done incorrectly. Backup your database before proceeding.

• Edit wp-config.php: Change $table_prefix = 'wp_'; to $table_prefix = 'x7z9_';.
• Rename Tables: Go to phpMyAdmin, select your database, and use the “Rename” command or run a bulk SQL query to rename every table starting with wp_ to x7z9_.
• Update References: You must update the wp_options and wp_usermeta tables because WordPress stores some permissions using the prefix key. Run these SQL commands:

SQL

UPDATE x7z9_options SET option_name = REPLACE(option_name, 'wp_', 'x7z9_') WHERE option_name LIKE 'wp_%';
UPDATE x7z9_usermeta SET meta_key = REPLACE(meta_key, 'wp_', 'x7z9_') WHERE meta_key LIKE 'wp_%';

Proceed with extreme caution or hire a Maintenance Expert

Securing Database Credentials and Connection

Your database password resides in plain text inside wp-config.php. It should be the strongest password you own.

• Length: Minimum 40 characters.
• Complexity: Use a random string generator.
• Scope: Do not use the same password for your FTP, Hosting Panel, and Database.

Restricting Database User Privileges

Most hosting auto-installers create a MySQL user with “ALL PRIVILEGES.” This means if a hacker hijacks the connection, they can DROP (delete) your entire database.

For day-to-day operations, WordPress does not need permission to delete the database.

How to harden this via cPanel/phpMyAdmin:

• Create a standard user for WordPress.
• Grant only the following data privileges: SELECT, INSERT, UPDATE, DELETE.
• Grant only the following structure privileges: CREATE, ALTER, INDEX, DROP (Note: DROP and ALTER are needed for some plugins and core updates to modify tables, but you can revoke these if you want an ultra-hardened “read-only” mode during non-maintenance periods).
• Revoke administrative privileges like GRANT and SHUTDOWN.

Regular Database Optimization and Cleanup

A bloated database is a security risk because it increases the surface area for DoS attacks (Database Exhaustion).

• Clean Transients: Old data that should have expired.
• Limit Revisions: As mentioned in the wp-config.php section, keep this low.
• Remove Spam: Empty the Spam and Trash folders regularly using SQL:

SQL

DELETE FROM wp_comments WHERE comment_approved = 'spam';

File and Folder Permissions: The CHMOD Guide

On a Linux server, every file and folder has a set of three permissions known as CHMOD (Change Mode). These permissions dictate who is allowed to Read, Write, or Execute a file.

If your permissions are too loose (e.g., 777), you are effectively leaving your front door wide open. If they are too strict, WordPress won’t be able to update itself or upload images.

Understanding Linux File Permissions

Permissions are represented by three numbers (e.g., 755).

• First Number (User): What you (the owner) can do.
• Second Number (Group): What the server group can do.
• Third Number (World): What everyone else (including the public internet) can do.

The Golden Rule: The “World” should never have Write access to anything.

Recommended Permissions for WordPress Directories

All folders (directories) should be set to 755.

• 7 (User): Read, Write, Execute (You can do anything).
• 5 (World): Read, Execute (Public can look, but not touch).
• 5 (Group): Read, Execute (Server can look, but not touch).

How to set this recursively:

• Connect via FTP software.
• Right-click the public_html (or root) folder and select File Permissions.
• Type 755 in the Numeric value box.
• Select Recurse into subdirectories.
• Select Apply to directories only.

Recommended Permissions for WordPress Files

All standard files (.php, .jpg, .css) should be set to 644.

• 6 (User): Read, Write.
• 4 (Group): Read only.
• 4 (World): Read only.

How to set this recursively:

1. Right-click public_html again and select File Permissions.
2. Type 644.
3. Select Recurse into subdirectories.
4. Crucial: Select Apply to files only.

Securing wp-config.php with Strict Permissions

As discussed earlier, wp-config.php is the master key. It requires tighter security than regular files.

• Standard Hardening: 440 (User and Group can read, no one can write).
• Paranoid Hardening: 400 (Only the User can read).

Note: If you set it to 400 and your site breaks, revert to 440 or 640. Some server configurations require the Group to read the file to serve the site.

HTTP Security Headers Implementation

Security headers are one of the most underrated aspects of WordPress security. They don’t protect the server from being hacked; they protect your users from being victimized while visiting your site.

What Are HTTP Security Headers and Why They Matter

When a user visits your site, your server sends back the website content (HTML) and a set of “headers” (metadata). By adding security headers, you can stop browsers from running unauthorized scripts, prevent your site from being embedded in hidden frames, and force secure connections.

Implementing Content-Security-Policy (CSP)

This is the most powerful header. It acts as a whitelist, telling the browser: “Only load scripts from these specific domains.” If a hacker injects a malicious script (XSS) that tries to load malware from evil-site.com, the browser will block it because it isn’t on the list.

Warning: CSP is complex. Setting it too strictly can break Google Analytics, YouTube embeds, or theme scripts. The example below is a “starter” policy that allows most standard WordPress resources.

Adding X-Frame-Options to Prevent Clickjacking

“Clickjacking” is when an attacker embeds your website inside an invisible <iframe> on their own site. When a user clicks a button on the attacker’s site, they are actually clicking a button on your site (like “Delete Account” or “Buy Now”).

• Setting: SAMEORIGIN (Your site can only be framed by itself).

Enabling X-Content-Type-Options

Sometimes browsers try to “guess” the file type. If a hacker uploads a .jpg file that actually contains executable code, the browser might try to run it. This header forces the browser to stick to the declared file type.

• Setting: nosniff.

Setting Up Strict-Transport-Security (HSTS)

This header forces the browser to always use HTTPS, even if the user types http://. It prevents “Man-in-the-Middle” attacks where a hacker intercepts the initial insecure connection.

• Warning: Only enable this if you have a valid SSL certificate. If your SSL expires, users will be completely locked out of your site.

Configuring Referrer-Policy and Permissions-Policy

• Referrer-Policy: Controls how much data (like the URL the user came from) is passed to other sites when they click a link.
• Permissions-Policy: Prevents your site from accessing browser features like the camera, microphone, or geolocation unless explicitly allowed.

Complete Security Headers Code for .htaccess

Copy and paste this block into your .htaccess file.

Apache

<IfModule mod_headers.c>
  # 1. Prevent Clickjacking
  Header always append X-Frame-Options SAMEORIGIN
  
  # 2. Block MIME Sniffing
  Header set X-Content-Type-Options nosniff
  
  # 3. Enable XSS Filter (Legacy protection for older browsers)
  Header set X-XSS-Protection "1; mode=block"
  
  # 4. Force HTTPS (HSTS) - Enable ONLY if SSL is working!
  # Caches the rule for 1 year (31536000 seconds)
  Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  
  # 5. Privacy: Only send referrer data to secure sites
  Header set Referrer-Policy "no-referrer-when-downgrade"
  
  # 6. Feature Policy: Disable access to Cam/Mic/Geolocation
  Header set Permissions-Policy "geolocation=(), camera=(), microphone=()"

  # 7. Basic Content Security Policy (Optional - Use with caution)
  # Un-comment the line below to enable. It allows scripts from your own site and Google (Analytics/Fonts).
  # Header set Content-Security-Policy "default-src 'self' https: data: 'unsafe-inline' 'unsafe-eval'; img-src 'self' https: data:;"
</IfModule>

SSL/HTTPS Configuration Without Plugins

Google has made HTTPS a ranking factor, and browsers now mark HTTP sites as “Not Secure.” A plugin-free setup ensures your encryption is handled at the server level, where it belongs.

Installing a Free SSL Certificate (Let’s Encrypt)

• Most modern hosts (cPanel, Plesk, etc.) offer free automated SSL certificates via Let’s Encrypt.
• Log in to your Hosting Control Panel.
• Look for “SSL/TLS Status” or “Let’s Encrypt”.
• Select your domain and click Run AutoSSL or Install.
• Wait for the success message.

Forcing HTTPS via .htaccess Redirect

Once the certificate is installed, you must force all visitors to use the secure version. If someone types http://yoursite.com, they should be instantly redirected to https://.

The Code (Apache): Add this to the very top of your .htaccess file:

Apache

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Note: The 301 code tells Google this is a permanent change, transferring your SEO rankings to the HTTPS version.

Updating WordPress URLs for HTTPS

You must tell WordPress itself that it is now a secure site.

• Go to Settings > General.
• Change WordPress Address (URL) to https://...
• Change Site Address (URL) to https://...
• Click Save Changes. (You will be logged out and asked to log in again).

Fixing Mixed Content Issues Manually

“Mixed Content” happens when your secure HTTPS page tries to load an insecure HTTP image or script. The browser padlock will disappear or show a warning.

How to fix it without a plugin:

1. Database Search & Replace: You need to update every link in your database.
   • Method A (WP-CLI): If you have SSH access, run: wp search-replace 'http://yoursite.com' 'https://yoursite.com' --all-tables
   • Method B (Script): Use a tool like Interconnect/IT Search Replace DB (a temporary script you upload, run, and delete).
   • Method C (SQL – Risky): Run SQL queries in phpMyAdmin (only recommended if you are comfortable with serialization).
2. Hardcoded Theme Files: Sometimes developers hardcode http:// in header.php or footer.php.
   • Download your theme folder.
   • Use a code editor (like VS Code) to “Find in Folder” for http://.
   • Replace relevant instances with https://.

Manual Malware Detection and Removal

The biggest downside of removing security plugins is losing the “dashboard” that tells you when something is wrong. To compensate, you must learn to read the signals your server is already generating.

Enabling and Reviewing WordPress Debug Logs

WordPress has a built-in debugging mode that writes errors to a file. This is useful for spotting PHP errors caused by malware or broken code.

Step 1: Enable Logging Add this to your wp-config.php:

PHP

define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false ); // Don’t show errors on screen

Step 2: Protect the Log File By default, the log is saved to /wp-content/debug.log, which is publicly accessible! You must either:

• Block access via .htaccess:

<Files debug.log>
Order allow,deny
Deny from all
</Files>

• Or change the log location in wp-config.php:

define( 'WP_DEBUG_LOG', '/home/username/private_logs/debug.log' );

Monitoring Server Error Logs (Apache/Nginx)

Your server logs every single request. If you see a spike in traffic but your analytics don’t show it, your server logs will tell the truth.

• cPanel: Go to Metrics > Errors or Raw Access.
• SSH (Apache): tail -f /var/log/apache2/access.log
• SSH (Nginx): tail -f /var/log/nginx/access.log

What to look for:

• Repeated POST requests: If you see hundreds of POST requests to xmlrpc.php or wp-login.php in a few minutes, you are under brute force attack.
• 404 Errors on Strange Files: If you see 404s for files like shell.php, bak.php, or admin.rar, bots are scanning your site for common backdoors.

Manual File Integrity Monitoring

How do you know if a hacker modified a core file? You use the Linux find command. If you have SSH access, run this command to see every file modified in the last 24 hours:

Bash

find /path/to/wordpress -type f -mtime -1

If you haven’t installed a plugin or updated a post, this list should be empty. If you see wp-includes/random-name.php, you have been hacked.

Setting Up Email Alerts for Suspicious Activity

You can add a simple snippet to your theme’s functions.php to email you whenever an administrative level user logs in. This acts as an early warning system.

PHP

function notify_admin_login( $user_login, $user ) {
    if ( in_array( 'administrator', (array) $user->roles ) ) {
        wp_mail( 'your-email@example.com', 'Admin Login Alert', 'User ' . $user_login . ' logged in at ' . date('Y-m-d H:i:s') );
    }
}
add_action( 'wp_login', 'notify_admin_login', 10, 2 );

Using Free External Monitoring Tools

Since you don’t have a plugin inside the site, use tools outside the site.

• Uptime Robot: Monitors if your site goes down (often the first sign of a hacked/overloaded server).
• Google Search Console: Check the Security & Manual Actions tab weekly. Google will often detect “Deceptive Pages” or malware before you do.

Manual Malware Detection and Removal

If you suspect your site has been compromised, do not panic. Hackers rely on obfuscation (hiding code) to stay undetected. Once you know where to look, their hiding spots become obvious.

Identifying Signs of a Compromised WordPress Site

Malware rarely announces itself. Look for these subtle anomalies:

• The “Pharma” Hack: Your site looks normal to you, but when you Google your brand name, the search results show ads for cheap pharmaceuticals or gambling.
• Conditional Redirects: You can browse the site fine, but visitors from mobile devices or Facebook are redirected to a scam site.
• Ghost Admins: A new user appears in the Users tab with a name like system_admin or wp_updater that you did not create.

Scanning Files for Malicious Code Patterns

Hackers often inject code into index.php, wp-config.php, or your theme’s header.php. They use functions that allow them to execute scrambled commands.

What to look for: Open your core files in a text editor. You are looking for “spaghetti code”—long strings of random characters that look like gibberish.

The “Grep” Method (SSH): If you have SSH access, you can scan every file on your server for common malware fingerprints in seconds. Run this command inside your public_html folder:

Bash

grep -rE "base64_decode|eval\(|gzinflate|shell_exec" .

• base64_decode: Decodes hidden text.
• eval(): Executes PHP code (extremely rare in legitimate themes).
• shell_exec: Allows the hacker to run server commands.

If you see these functions in a file that isn’t a known library, it is likely malware.

Checking the Database for Injected Content

Sometimes files are clean, but the database is infected. This is common with “Japanese Keyword Hacks” or spam injections.

1. Open phpMyAdmin.
2. Select your database and click the Search tab.
3. Search for common malicious terms: <script, display:none, or unexpected domains.
4. Select all tables and click Go.

Step-by-Step Manual Malware Cleanup Process

The only way to be 100% safe is to replace the infected files with fresh, official copies. Do not try to surgically remove the code line-by-line. You will miss something.

1. The Lockdown Change all passwords (database, FTP, Hosting Panel, Admin). Put the site in maintenance mode.

2. The Core Replacement (The Safe Way) Most malware hides in WordPress core files (wp-includes and wp-admin).

• Download a fresh .zip of WordPress from wordpress.org.
• Connect via FTP.
• Delete the wp-admin and wp-includes folders entirely. (Do NOT delete wp-content or wp-config.php).
• Upload the fresh wp-admin and wp-includes folders from your download.

3. The Content Audit You cannot delete wp-content because it holds your uploads and themes. You must inspect it manually.

• Check inside /wp-content/uploads/. If you see any .php files here, delete them. Images should never be executable scripts.
• Check inside /wp-content/plugins/. The safest method is to delete all plugin folders and re-download fresh copies from the plugin repository.

4. The Config Cleanse Open wp-config.php. Compare it to the wp-config-sample.php file. If you see strange code at the top or bottom (often referring to a temporary file), delete it.

Hosting-Level Security Measures

Your hosting provider is the foundation of your security architecture. If you build a bank vault on a sinkhole, it will still collapse. In a “No-Plugin” strategy, we rely heavily on the host’s native features to do the heavy lifting that plugins usually do.

Choosing a Secure WordPress Host: What to Look For

Stop using “unlimited” shared hosting for $2/month. These environments often pack thousands of sites onto one server, meaning if your neighbour gets hacked, the malware can sometimes “jump” to your site (cross-site contamination).

The Agency’s Choice: GridPane Security Features

For those managing their own VPS (on DigitalOcean, Vultr, Linode, or Hetzner), GridPane offers one of the most robust “No-Plugin” security stacks available. It automates the advanced hardening techniques we discussed earlier directly at the server level.

1. The 6G/7G Web Application Firewall (Nginx) Instead of installing a plugin to check every request, GridPane integrates the Perishable Press 7G Firewall directly into the Nginx server block.

• How it works: It scans the Request URI and User Agent strings against a list of known malicious patterns.
• The Benefit: It blocks bad bots, SQL injection attempts, and directory traversal attacks before they ever touch WordPress or PHP. This is zero-latency security.

2. Deep Fail2Ban Integration GridPane comes pre-configured with Fail2Ban rules specifically for WordPress.

• Log Monitoring: It watches your access.log and error.log in real-time.
• Instant Banning: If an IP attempts to brute force wp-login.php or hits a “forbidden” URL too many times, Fail2Ban adds that IP to the server’s system firewall (iptables). The attacker is completely cut off from the server, not just the website.

3. System User Isolation Unlike standard shared hosting, GridPane creates a unique Linux system user for every single website on the server.

• Why this matters: If “Site A” gets hacked, the malicious script is trapped within that user’s permissions. It physically cannot read or write the files of “Site B” on the same server, preventing cross-contamination.

Using cPanel Security Features (ModSecurity, IP Blocker)

If you are on standard shared hosting (cPanel), you have powerful tools pre-installed that most users ignore.

1. ModSecurity (The Server-Side WAF) ModSecurity is an open-source firewall that runs on Apache. It does exactly what Wordfence does (blocking SQL injections and XSS attempts) but handles it before the request hits WordPress.

• Action: Log in to cPanel > Look for ModSecurity > Ensure it is switched to “On”.

2. IP Blocker This provides a graphical interface for the “Deny IP” rules in your .htaccess file.

• Action: If you notice a specific IP spamming your contact form, paste it here to ban them permanently.

Setting Up Server-Side Firewalls

If you manage your own VPS, you are responsible for the firewall. You should configure UFW (Uncomplicated Firewall).

The Strategy: Close every port except the ones you absolutely need.

• Port 80/443: Open (Web Traffic).
• Port 22: Open (SSH – restricted to your IP if possible).
• All others: Closed.

Configuring SSH Access and Key Authentication

Using a password for SFTP or SSH is a vulnerability. Passwords can be brute-forced; SSH Keys cannot.

How to implement:

• Generate an SSH Key pair on your computer (public and private keys).
• Upload the Public Key to your server (~/.ssh/authorized_keys).
• Disable password authentication in your server’s sshd_config file:

Bash

PasswordAuthentication no
PermitRootLogin no

Now, only a computer holding your specific private key file can connect to the server.

Leveraging CDN Security Features (Cloudflare Free Tier)

This is the single most important step for a No-Plugin setup. Cloudflare sits between the internet and your server.

1. Bot Fight Mode Cloudflare analyzes patterns from millions of sites. If a request comes from a known malicious bot, Cloudflare challenges them (with a CAPTCHA) before they reach your site.

• Action: Go to Security > Bots > Toggle Bot Fight Mode to On.

2. Firewall Rules (WAF) On the free plan, you get 5 custom firewall rules. Use them to block access to your login page from high-risk countries.

• Rule Logic:
  • If URI path contains /wp-login.php
  • AND Country is NOT [Your Country]
  • THEN Block (or Challenge).

Comment Spam Prevention Without Plugins

Comment spam is not just annoying; it is a database performance killer. Every time a bot submits a comment, your database has to write a new row. If 10,000 bots hit you at once, your site slows to a crawl.

Most people install heavy plugins to filter this. In a “No-Plugin” setup, we simply stop the bots from submitting the form in the first place.

Disabling Comments Entirely (If Unused)

If you run a business brochure site, you likely do not need comments. Leaving them on is a security liability.

How to disable:

1. Go to Settings > Discussion.
2. Uncheck “Allow people to submit comments on new posts.”
3. Existing Posts: This setting only applies to future posts. To close old ones, go to Posts > All Posts, select all, click Bulk Actions > Edit, and change “Comments” to Do not allow.

Adding a Honeypot Field via functions.php

A “Honeypot” is a trap. We create a fake input field (e.g., named “phone_number”) and hide it with CSS so human users can’t see it. Bots, however, read the code and blindly fill in every field. If the hidden field has data, we know it’s a bot and reject the comment instantly.

The Code: Add this to your theme’s functions.php file:

PHP

// 1. Add the hidden field to the comment form
function add_honeypot_field() {
    echo '<p style="display:none;"><label>Do not fill this out</label><input name="bot_trap" type="text" /></p>';
}
add_action( 'comment_form', 'add_honeypot_field' );

// 2. Check if the field is filled
function check_honeypot( $commentdata ) {
    if ( ! empty( $_POST['bot_trap'] ) ) {
        // Stop processing and kill the script
        wp_die( 'Spam detected. You filled out a hidden field.' );
    }
    return $commentdata;
}
add_filter( 'preprocess_comment', 'check_honeypot' );

Implementing Time-Based Comment Restrictions

Humans take time to read and type. Bots submit forms in milliseconds. We can reject any comment submitted less than 5 seconds after the page loads.

The Code: Add this to functions.php:

PHP

// Check for fast submissions (under 5 seconds)
function check_comment_speed( $commentdata ) {
    // Basic logic: You would need to set a timestamp cookie on page load
    // and compare it here. (Omitted for brevity as Honeypot is usually sufficient).
    return $commentdata;
}

Note: For a pure no-plugin setup, the Honeypot method above is generally more reliable than time-based checks, which can be affected by caching plugins.

Blocking Spam via .htaccess Rules

Bots often skip your website entirely and send POST requests directly to wp-comments-post.php to save time. We can block anyone who tries to post a comment without actually visiting the page (no “Referrer”).

The Code (Apache): Add this to your .htaccess file:

Apache

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*yoursite.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]
</IfModule>

Translation: “If you try to POST a comment, but your ‘Referrer’ (previous page) was not mywebsite.com, get lost.”

Creating a Manual Security Maintenance Schedule

When you remove automated security plugins, you become the security guard. This doesn’t mean you need to watch the logs 24/7, but it does require a disciplined routine.

Daily Security Tasks

• Check Uptime: Use a free tool like Uptime Robot. If your site goes down, investigate immediately.
• Visual Check: Briefly visit your homepage and a few internal pages to ensure no layout shifts or strange ads (signs of injection).

Weekly Security Tasks

• Core Updates: Log in and run updates for WordPress core, themes, and plugins.
• Backup Verification: Check your server or remote storage (e.g., Dropbox/S3) to ensure your automated backup files are actually being created.
• User Audit: Glance at the “Users” tab. Are there any new Administrators you don’t recognize?

Monthly Security Audit Checklist

• Change Passwords: Update your main Administrator password.
• Review Logs: Check your server’s Error Log (via cPanel or SSH) for repeated attacks from specific IPs. Ban them if necessary.
• Database Cleanup: Run the SQL commands mentioned earlier to clear transients and spam comments.

Quarterly Deep Security Review

• Key Rotation: Generate new salts and keys for your wp-config.php file to logout all sessions.
• Test Restore: The only way to know if a backup works is to try restoring it to a staging site.
• Plugin Audit: Review every installed plugin. Has it been abandoned by the developer? If it hasn’t been updated in 6 months, replace it.

When You Should Consider Using a Security Plugin

We are advocates of the “No-Plugin” approach, but we are not dogmatic. There are specific scenarios where installing a plugin is the smarter business decision.

Limitations of the No-Plugin Approach

• No GUI: You don’t get pretty charts or email summaries.
• Human Error: One typo in .htaccess breaks the site.
• Reactive vs Proactive: Manual log checking is reactive. You often find out about a hack after it happens.

Scenarios Where Plugins Make Sense

• Non-Technical Clients: If you are handing a site over to a client who cannot use FTP, install a lightweight plugin so they have some protection.
• Frequent File Changes: If you have multiple editors uploading files constantly, a real-time file scanner (like Wordfence) might be necessary to catch accidental malware uploads.
• Compliance: Some industries (finance/health) require “active intrusion detection systems” for compliance.

Lightweight Plugin Alternatives for Specific Tasks

If you need specific features but don’t want the bloat of a full suite:

• BBQ Firewall: A lightweight WAF that does essentially what our .htaccess rules do, but manages it via a plugin.
• Two-Factor: Use a dedicated 2FA plugin if you find the Basic Auth method too intrusive for your users.
• Limit Login Attempts Reloaded: Does one thing (blocks brute force) and does it well.

Complete No-Plugin Security Implementation Checklist

Use this checklist to ensure you haven’t missed a step in hardening your site.

Server & Network

1. [ ] Hosting environment uses Containerisation (CloudLinux/LXC) or is a VPS.
2. [ ] SSH Keys configured; Password Authentication disabled.
3. [ ] Cloudflare (or similar CDN) enabled with Bot Fight Mode on.
4. [ ] Firewall (GridPane/UFW/ModSecurity) active and blocking unused ports.

WordPress Configuration

1. [ ] wp-config.php moved above web root (if possible).
2. [ ] DISALLOW_FILE_EDIT set to true.
3. [ ] WP_DEBUG set to false.
4. [ ] Unique Authentication Keys and Salts generated.
5. [ ] Table prefix changed from wp_ (on new installs).

File Permissions & Rules

1. [ ] Directories set to 755; Files set to 644.
2. [ ] wp-config.php set to 400 or 440.
3. [ ] .htaccess rules added to block XML-RPC.
4. [ ] .htaccess rules added to prevent PHP execution in /uploads.
5. [ ] HTTP Security Headers (HSTS, X-Frame-Options) implemented.

Authentication

1. [ ] Admin username is NOT “admin”.
2. [ ] Login page protected via IP Whitelist or Basic Auth.
3. [ ] REST API restricted to logged-in users only.

Conclusion: Taking Full Control of Your WordPress Security

Implementing the “No-Plugin” security guide is a journey from reliance to resilience. By hardening wp-config.php, mastering .htaccess, and utilizing server-side protection, you create a WordPress site that is not only fortified against 99% of attacks but also significantly faster.

Security is not a product you install; it is a process you maintain.

Need help implementing these advanced rules? Editing server files isn’t for everyone. Our WordPress Maintenance Services can handle the technical hardening for you. If you have already suffered a breach, consult our team to help restore your site and reputation.