Security Solutions
& Fix Guides

Most hosts offer one-click SSL. In cPanel go to SSL/TLS → Let's Encrypt. On the command line: sudo certbot --apache -d yourdomain.com

Install Really Simple SSL plugin and click Activate SSL, or add to wp-config.php:
define('FORCE_SSL_ADMIN', true);

Certificates expire every 90 days. Run sudo certbot renew --dry-run to confirm auto-renewal is set. Most hosts handle this automatically.

Edit your SSL virtual host config and set:
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
Then restart: sudo systemctl restart apache2

In your nginx.conf or site config:
ssl_protocols TLSv1.2 TLSv1.3;
Reload: sudo nginx -s reload

In WHM go to Service Configuration → Apache Configuration → Global Configuration and uncheck TLS 1.0 and 1.1 under SSL/TLS Protocols.

Add to your .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Add a server block:
server { listen 80; server_name yourdomain.com; return 301 https://$host$request_uri; }

The Really Simple SSL plugin handles this automatically, including fixing mixed content URLs.

In your SSL virtual host, set:
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder on

In nginx.conf:
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

Visit ssl-config.mozilla.org, select your server and profile (Modern/Intermediate), and copy the generated configuration directly.

Header always set Expect-CT "max-age=86400, enforce"
Note: Only add the enforce directive after verifying your certificate is in CT logs.

add_header Expect-CT "max-age=86400, enforce" always;

Use crt.sh to search for all certificates ever issued for your domain. Set up alerts at CertSpotter to be notified of new certificate issuance.

Add to your SSL virtual host:
SSLUseStapling on
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
The cache directive goes in the global config, not inside a VirtualHost.

Add to your server block:
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Use HTTP Headers by WebFactory or Solid Security (formerly iThemes Security) to add HSTS without server access.

Add to your server config:
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'unsafe-inline' https://trusted-cdn.com;

HTTP Headers by WebFactory or WP Content Security Policy help you build and apply a policy without touching server config.

Once report-only shows no violations, switch to enforcement: Content-Security-Policy. Add nonces for inline scripts if needed.

Header always set X-Frame-Options "SAMEORIGIN"

add_header X-Frame-Options "SAMEORIGIN" always;

Add to the top of your .htaccess:
<IfModule mod_headers.c>
Header set X-Frame-Options "SAMEORIGIN"
</IfModule>

Apache: Header always set X-Content-Type-Options "nosniff"
Nginx: add_header X-Content-Type-Options "nosniff" always;

Referrer-Policy: strict-origin-when-cross-origin
This is the recommended modern default — sends origin only on cross-site requests.

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
Only allow features your site actually uses.

Cross-Origin-Opener-Policy: same-origin
This severs the browsing context group from cross-origin openers. Use same-origin-allow-popups if your site uses OAuth or payment popups that need to communicate back.

Header always set Cross-Origin-Opener-Policy "same-origin"

In your server block:
add_header Cross-Origin-Opener-Policy "same-origin" always;

Cross-Origin-Resource-Policy: same-site
Use same-origin for stricter control, or cross-origin only for public CDN assets that are intentionally shared.

Header always set Cross-Origin-Resource-Policy "same-site"

add_header Cross-Origin-Resource-Policy "same-site" always;

Header always set Cross-Origin-Embedder-Policy "require-corp"
Note: This requires all subresources to opt-in via CORP or CORS headers. Test in report-only mode first: Cross-Origin-Embedder-Policy-Report-Only: require-corp

add_header Cross-Origin-Embedder-Policy "require-corp" always;

Third-party resources (fonts, images, scripts) must serve either a Cross-Origin-Resource-Policy: cross-origin header or be served with CORS (Access-Control-Allow-Origin: *). Check browser DevTools console for COEP violations before enforcing.

Header always set X-XSS-Protection "1; mode=block"
The mode=block directive tells the browser to block the entire page rather than sanitize and render it.

add_header X-XSS-Protection "1; mode=block" always;

X-XSS-Protection is a legacy mechanism. Implement a full Content Security Policy (CSP) as the primary XSS defense — X-XSS-Protection complements it for older browsers that don't support CSP.

Add to your VirtualHost or .htaccess for protected areas:
<LocationMatch "^/(wp-admin|account|dashboard|checkout)">
Header always set Cache-Control "no-store, no-cache, must-revalidate"
Header always set Pragma "no-cache"
</LocationMatch>

Add to functions.php:
add_filter('wp_headers', function($headers) {
if (is_user_logged_in() || is_account_page() || is_checkout()) {
$headers['Cache-Control'] = 'no-store, no-cache, must-revalidate';
}
return $headers;
});

In Cloudflare, use Page Rules to set Cache Level to "Bypass" for /wp-admin/*, /account/*, and /checkout/*. In WP Rocket or W3 Total Cache, exclude these pages from caching in their respective settings.

Use srihash.org to generate hashes. Then update your script/link tags:
<script src="https://cdn.example.com/lib.js"
integrity="sha384-abc123..."
crossorigin="anonymous"></script>

Add to functions.php:
add_filter('script_loader_tag', function($tag, $handle, $src) {
$sris = ['jquery-cdn' => 'sha384-your-hash-here'];
if (isset($sris[$handle])) {
$tag = str_replace('>', ' integrity="' . $sris[$handle] . '" crossorigin="anonymous">', $tag);
}
return $tag;
}, 10, 3);

The safest approach is to self-host JavaScript libraries (jQuery, Bootstrap, etc.) rather than loading from external CDNs. This removes the third-party dependency risk entirely and often improves page load speed.

Add to functions.php:
remove_action('wp_head', 'wp_generator');

Plugins like WP Hide & Security Enhancer or WPS Hide Login change the default paths bots scan for.

Add to functions.php:
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');

Add to functions.php:
remove_action('wp_head', 'wp_generator');

Add to functions.php:
add_filter('style_loader_src', function($src){ return remove_query_arg('ver', $src); });
add_filter('script_loader_src', function($src){ return remove_query_arg('ver', $src); });

The RSS feed also exposes the version. Add: add_filter('the_generator', '__return_empty_string');

Add to your .htaccess:
<Files readme.html>
Order Allow,Deny
Deny from all
</Files>

Delete /readme.html from your WordPress root. It is not needed for site operation. Also delete readme.txt and license.txt.

Add to .htaccess (before WordPress block):
RewriteCond %{QUERY_STRING} ^author=\d
RewriteRule ^ - [F]

Solid Security (iThemes) and Wordfence both have user enumeration blocking built-in under Brute Force Protection settings.

Add to functions.php:
add_filter('rest_endpoints', function($endpoints){ unset($endpoints['/wp/v2/users']); unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']); return $endpoints; });

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

add_filter('xmlrpc_enabled', '__return_false');

Use the Disable XML-RPC plugin which blocks external requests while still allowing Jetpack to function internally.

Install WPS Hide Login and set a custom slug like /my-secret-door under Settings → WPS Hide Login.

Wordfence or Solid Security limit login attempts and add CAPTCHA challenges. This is more robust than obscurity alone.

In .htaccess:
<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from YOUR.OFFICE.IP
</Files>

Add to functions.php:
add_filter('rest_endpoints', function($endpoints){ if (!is_user_logged_in()) { unset($endpoints['/wp/v2/users']); unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']); } return $endpoints; });

Both plugins include REST API user enumeration blocking in their settings under the API section.

Add to your .htaccess:
<Files license.txt>
Order Allow,Deny
Deny from all
</Files>

Delete /license.txt from your WordPress root. It is not needed for site operation. You should also delete readme.html and readme.txt while you're there.

Go to Users → Add New. Create a new account with a unique, non-obvious username and assign the Administrator role. Use a strong, random password.

Log out, then log in as the new administrator. Go to Users, hover over the "admin" user, and click Delete. When prompted, choose Attribute all content to your new account.

Under Users → Profile, set Display name publicly as to your full name or pen name — never your login username.

Go to Settings → Discussion and uncheck:
• "Allow link notifications from other blogs (pingbacks and trackbacks)"
• "Attempt to notify any blogs linked to from the article"
Click Save Changes.

Add to functions.php:
add_filter('xmlrpc_methods', function($methods) {
unset($methods['pingback.ping']);
unset($methods['pingback.extensions.getPingbacks']);
return $methods;
});

Add to functions.php:
add_filter('wp_headers', function($headers) {
unset($headers['X-Pingback']);
return $headers;
});

Go to Settings → General and uncheck Anyone can register. Set the New User Default Role to Subscriber even if you do need registration.

Install WPForms or Simple Cloudflare Turnstile to add CAPTCHA to your registration form. This blocks automated bot registrations.

Use WP-Members or User Registration plugin to require email confirmation before accounts become active. This prevents fake/spam registrations.

Add to functions.php:
remove_action('wp_head', 'wlwmanifest_link');

Add alongside:
remove_action('wp_head', 'rsd_link');
Both are legacy blogging client discovery endpoints with no value on modern WordPress sites.

Add to functions.php:
add_filter('heartbeat_settings', function($settings) {
$settings['interval'] = 60;
return $settings;
});

add_action('init', function() {
if (!is_admin()) wp_deregister_script('heartbeat');
});

Install Heartbeat Control by WP Rocket (free) for a GUI to configure per-page heartbeat frequency or disable it entirely without code.

In Cloudflare, create a rate limiting rule targeting POST requests to /wp-admin/admin-ajax.php from non-logged-in IPs. Set a threshold of 10 requests/minute.

Open wp-config.php and set:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Even if you need error logging, never display errors to users. Use WP_DEBUG_LOG to write to a log file, and set WP_DEBUG_DISPLAY to false.

Enable WP_DEBUG only on staging/development environments. Most hosting control panels (cPanel, RunCloud, Kinsta) let you create staging clones in one click.

Go to Dashboard → Updates and click "Update to [latest version]". WordPress will download and install the update automatically. Always back up first.

In wp-config.php, add:
define('WP_AUTO_UPDATE_CORE', true);
This enables automatic security and minor release updates.

Via SSH: wp core update && wp core update-db

Before any update, create a full backup with UpdraftPlus or your host's backup tool. This gives you a rollback point if anything breaks.

Add this to wp-config.php:
define('DISABLE_WP_CRON', true);

Add a cron job to your server:
*/5 * * * * curl -s https://yourdomain.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
Or via WP-CLI:
*/5 * * * * wp cron event run --due-now

Once you use a real server cron, optionally block the HTTP endpoint in .htaccess:
<Files "wp-cron.php">
  Order allow,deny
  Deny from all
</Files>

Add to your theme's functions.php or a custom plugin:
add_filter('rest_authentication_errors', function($result) {
  if (!is_user_logged_in()) {
    return new WP_Error('rest_not_logged_in', 'Authentication required.', ['status' => 401]);
  }
  return $result;
});

To only block user enumeration:
add_filter('rest_endpoints', function($endpoints) {
  if (isset($endpoints['/wp/v2/users'])) unset($endpoints['/wp/v2/users']);
  return $endpoints;
});

Disable REST API or Solid Security offer settings to restrict REST API access without writing code.

Go to Plugins → Add New and search "Wordfence". Install and activate. Run the Setup Wizard to configure the firewall, malware scanner, and brute-force protection.

Solid Security is another excellent free option with 2FA, brute-force protection, and security hardening. Available from the WordPress plugin repository.

Sucuri offers both a free WordPress plugin (auditing, blacklist monitoring) and a premium cloud WAF that filters traffic before it reaches your server.

Add to wp-config.php:
define('DISALLOW_FILE_EDIT', true);
This removes the Appearance → Theme Editor and Plugins → Plugin Editor menu items entirely.

To also prevent plugin and theme installation/deletion via the dashboard:
define('DISALLOW_FILE_MODS', true);
Note: This also blocks automatic core updates, so manage updates via WP-CLI or staging instead.

Go to Plugins → Installed Plugins. Click Update Available to filter, then select all and use Bulk Actions → Update. Always backup first.

For each plugin, click Enable auto-updates in the plugin list. Or add to functions.php:
add_filter('auto_update_plugin', '__return_true');

Via SSH: wp plugin update --all
Check for updates: wp plugin status

If a plugin hasn't been updated in over 2 years, check the WordPress.org page for its "Last Updated" and "Tested up to" fields. Abandoned plugins with no maintained security patches should be replaced with maintained alternatives.

Go to Appearance → Themes, hover over your active theme and click Update if available. Back up your child theme customizations first.

Keep only your active theme and one default WordPress theme (for emergency recovery). Delete all others via Appearance → Themes → Theme Details → Delete.

Never directly modify a parent theme — create a child theme instead. This allows parent theme updates without overwriting your customizations.

In wp-config.php before installing, change:
$table_prefix = 'wp_';
to something like:
$table_prefix = 'sp7x_'; (use a random alphanumeric string).

Use Solid Security (iThemes) → Tools → Change Database Table Prefix. Always take a full database backup before this operation.

wp search-replace wp_ newprefix_ --include-cols=option_name,user_meta --precise --no-report
Then rename the actual tables in MySQL. This is complex — use a plugin instead unless you're experienced.

Visit api.wordpress.org/secret-key/1.1/salt/ to generate fresh random keys. This page generates new unique values every time you load it.

Open wp-config.php and find the eight define('AUTH_KEY'... lines. Replace the entire block with the newly generated values. Logged-in users will be logged out automatically — this is expected.

Rotating salt keys invalidates all existing sessions immediately. This is a useful emergency response when you suspect a session has been compromised.

Install Simple Cloudflare Turnstile plugin and enable it on the login page. Turnstile is free and privacy-friendly — it requires no user interaction for legitimate users (passes automatically).

Wordfence includes a reCAPTCHA option for the login form under Wordfence → Login Security. Uses Google reCAPTCHA v3 (invisible).

In addition to CAPTCHA, configure Wordfence or Solid Security to lock out IPs after 3–5 failed login attempts. Set lockout duration to 30+ minutes.

Install WP Activity Log (free) — the most comprehensive WordPress audit trail plugin. It logs admin logins, content changes, plugin/theme changes, settings updates, and user activity.

In WP Activity Log settings, set a reasonable log retention period (90+ days). Enable email alerts for critical events like new admin account creation, plugin installation, and failed logins.

Logs stored in WordPress's own database can be tampered with by an attacker who gains access. Use WP Activity Log's integration with external logging services (Papertrail, Loggly, Slack) to preserve logs off-site.

Create a .htaccess file inside /wp-content/uploads/ with:
<Files *.php>
Order Deny,Allow
Deny from all
</Files>

Add to your server block:
location ~* /wp-content/uploads/.*\.php$ {
deny all;
return 403;
}

Extend the block to cover: .php, .php5, .phtml, .phar, .cgi, .pl, .py. Malicious uploads often use alternate extensions.

Put your site behind Cloudflare. The free plan includes DDoS protection, bot fighting, and basic security rules. The paid plans add the full OWASP rule set and custom firewall rules.

Wordfence includes an application-level WAF that runs within WordPress, blocking SQL injection, XSS, malicious file upload, and known exploit patterns before they reach your database.

Sucuri's WAF proxies all traffic through their infrastructure, filtering attacks before they reach your server. Includes virtual patching for known WordPress vulnerabilities.

Install UpdraftPlus — the most popular WordPress backup plugin. Configure daily database backups and weekly file backups. Store backups remotely to Google Drive, Dropbox, or Amazon S3 — never just on your server.

Set UpdraftPlus to keep at least 7 daily and 4 weekly backups. In the event of a slow-burn compromise, you need to be able to restore a clean copy from before the infection began.

A backup you've never tested is not a backup. Quarterly, perform a test restore to a staging site to confirm backups are complete and restorable. UpdraftPlus has a built-in one-click restore.

Add to functions.php:
add_filter('graphql_request_data', function($request_data) {
if (!is_user_logged_in() && isset($request_data['query']) && strpos($request_data['query'], '__schema') !== false) {
return ['query' => '{ __typename }'];
}
return $request_data;
});

Install a GraphQL security layer that disables introspection in production while allowing it in development environments based on authentication status or environment variable.

If you installed WPGraphQL for a plugin dependency but don't actively use it, restrict the /graphql endpoint to authenticated users or internal IP ranges only.

In Cloudflare Dashboard → Security → WAF → Rate Limiting Rules, create a rule:
URL: /wp-login.php, Threshold: 5 requests / 1 minute, Action: Block for 1 hour.

In Wordfence → Firewall → Brute Force Protection, set "Lock out after X login failures" to 5 attempts, with a 30-minute lockout. Enable "Immediately block IPs that use an invalid username".

Add to your Nginx config:
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location = /wp-login.php {
limit_req zone=login burst=3 nodelay;
}

The recommended permissions for WordPress are:
# Directories
find /var/www/html -type d -exec chmod 755 {} \;
# Files
find /var/www/html -type f -exec chmod 644 {} \;
# wp-config.php
chmod 440 /var/www/html/wp-config.php

chmod 400 wp-config.php (only owner can read) or chmod 440 (owner and group can read). This prevents other server users from reading your database credentials.

777 means all users on the server can read, write, and execute the file. On shared hosting, this means all other sites on the server can access your files. Only uploads directories occasionally need 755 for the web server to write to them.

Add to your main .htaccess (outside the WordPress BEGIN/END block):
RewriteEngine On
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]

Certain files like wp-includes/js/tinymce/wp-tinymce.php may be needed. Test your site after adding the rule and whitelist any that legitimately need to be accessible.

Go to Users → All Users and filter by Role: Administrator. For each admin account, verify it belongs to an active person who genuinely needs admin access.

For users who only write posts, change their role to Editor or Author. For users who need no login access, remove the account entirely. Click the username → Edit → Role → Change and Update.

Use the Two Factor plugin to require 2FA for all administrator accounts. See the 2FA guide in this knowledge base.

In wp-config.php:
define('WP_AUTO_UPDATE_CORE', 'minor');
This enables automatic minor and security releases (4.x.1, 4.x.2) but not major version jumps.

In wp-config.php:
add_filter('auto_update_plugin', '__return_true');
Or enable per-plugin in the Plugins list by clicking "Enable auto-updates" for each one.

If you manage multiple WordPress sites, tools like ManageWP or MainWP let you manage and apply updates across all sites from a single dashboard, with backup-before-update options.

Install Complianz – GDPR/CCPA Cookie Consent (free) or CookieYes. Both auto-scan your site for cookies, generate a privacy policy, and present a compliant consent banner.

At minimum, distinguish between: Necessary (always on), Analytics (opt-in), Marketing/Advertising (opt-in), and Social Media (opt-in). Block tracking scripts until consent is given.

WordPress provides a privacy policy template under Settings → Privacy. Customize it to list all cookies your site uses, what data you collect, and how it's processed.

Akismet comes bundled with WordPress. Go to Plugins → Installed Plugins, activate Akismet, and get a free API key at akismet.com (free for personal use).

Go to Settings → Discussion and enable Comment must be manually approved. Also enable Comment author must have a previously approved comment to whitelist known good commenters.

Install Antispam Bee (free) which adds an invisible honeypot field to the comment form. Bots that fill in hidden fields are automatically rejected without CAPTCHA friction for real users.

Edit /etc/apache2/apache2.conf (or httpd.conf) and add:
ServerTokens Prod
ServerSignature Off

In nginx.conf inside the http {} block:
server_tokens off;

If you use Cloudflare, enable Security Level and use Transform Rules to remove the Server header entirely.

Find and edit php.ini (run php --ini to find it) and set:
expose_php = Off
Then restart your web server.

Header unset X-Powered-By
Requires mod_headers enabled.

proxy_hide_header X-Powered-By;
fastcgi_hide_header X-Powered-By;

Review each Disallow: line. Remove entries that reveal sensitive infrastructure paths. Protecting a path from crawlers is not security — anyone can read robots.txt.

Instead of hiding paths in robots.txt, protect the real resources: require authentication, add IP restrictions, or block access in .htaccess / Nginx config.

A common minimal approach: User-agent: *\nDisallow: /wp-admin/ — this is already public knowledge for WordPress sites and avoids revealing custom paths.

In your Apache config or .htaccess:
<Location "/server-status">
Require ip 127.0.0.1
Require ip YOUR.OFFICE.IP
</Location>
Or disable mod_status entirely: sudo a2dismod status && sudo systemctl restart apache2

Add a location block:
location /server-status {
deny all;
return 404;
}

The /server-info endpoint reveals loaded Apache modules, configuration directives, and compile-time settings. Apply the same IP restriction or disable mod_info.

Edit php.ini and set:
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php-errors.log
Restart Apache or PHP-FPM after changes.

Add to your .htaccess:
php_flag display_errors Off
php_flag log_errors On

In wp-config.php:
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Add to .htaccess:
<FilesMatch "^(CHANGELOG|CHANGES|HISTORY|RELEASE_NOTES|UPGRADING)(\.md|\.txt|\.rst)?$">
Deny from all
</FilesMatch>

location ~* ^/(CHANGELOG|CHANGES|HISTORY|RELEASE_NOTES)(\.md|\.txt|\.rst)?$ {
deny all;
return 404;
}

Best practice is to exclude documentation files from your deployment entirely. In your CI/CD pipeline or rsync command:
rsync --exclude="CHANGELOG*" --exclude="*.md" src/ dest/

Log into Cloudflare Dashboard → select your domain → Caching → Configuration → Development Mode → toggle Off.

Configure your origin server's firewall to only accept HTTP/HTTPS connections from Cloudflare's published IP ranges. Block all other sources on ports 80/443. This prevents attackers from bypassing Cloudflare to reach your origin directly.

If you're purging cache during testing, use Caching → Purge Cache → Purge Everything instead of enabling Dev Mode. This clears cached content without disabling security.

The plugin auto-corrects HTTP URLs in content, options, and the database on activation.

Use Better Search Replace plugin to replace all http://yourdomain.com with https://yourdomain.com in the database.

As a fallback, add to your CSP: Content-Security-Policy: upgrade-insecure-requests — this tells browsers to upgrade HTTP resource requests to HTTPS automatically.

Add to wp-config.php:
define('COOKIE_SECURE', true);
define('COOKIE_HTTPONLY', true);

In php.ini:
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = "Strict"

For all cookies, add via Apache:
Header edit Set-Cookie ^(.*)$ $1;Secure;HttpOnly;SameSite=Strict

Add to .htaccess (or main server config):
Options -Indexes

In your server block: autoindex off;

Place a blank index.php file (just <?php // silence) inside directories that should not be browsable.

Replace the wildcard with an allowlist:
SetEnvIf Origin "^https://(yourdomain\.com|app\.yourdomain\.com)$" CORS_ORIGIN=$0
Header always set Access-Control-Allow-Origin "%{CORS_ORIGIN}e" env=CORS_ORIGIN

set $cors_origin "";
if ($http_origin ~* "^https://(yourdomain\.com|app\.yourdomain\.com)$") {
set $cors_origin $http_origin;
}
add_header Access-Control-Allow-Origin $cors_origin;

Add to functions.php:
add_action('rest_api_init', function() {
remove_filter('rest_pre_serve_request', 'rest_send_cors_headers');
add_filter('rest_pre_serve_request', function($value) {
$allowed = ['https://yourdomain.com'];
$origin = $_SERVER['HTTP_ORIGIN'] ?? '';
if (in_array($origin, $allowed)) {
header('Access-Control-Allow-Origin: ' . $origin);
}
return $value;
});
});

Add to functions.php:
add_filter('auth_cookie_expiration', function($expiration, $user_id, $remember) {
return $remember ? (7 * DAY_IN_SECONDS) : (4 * HOUR_IN_SECONDS);
}, 10, 3);

Ensure the "Remember Me" checkbox is not pre-checked on the login form. Add to functions.php:
add_filter('login_footer', function() {
echo '<script>document.getElementById("rememberme").checked=false;</script>';
});

Solid Security includes an "Away Mode" and idle session logout feature under Security → Settings → User Groups → Logout Idle Users.

Never transmit secrets via GET parameters. Use HTTP POST requests with the data in the request body, or pass API keys via Authorization headers: Authorization: Bearer your-token-here

Search your codebase for $_GET['password'], $_GET['token'], $_GET['key']. Replace with $_POST or header-based retrieval.

Add Referrer-Policy: no-referrer to prevent URL parameters from being sent to third-party sites in Referrer headers if you cannot immediately fix the URL issue.

Add to your .htaccess:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?yourdomain\.com/ [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp|svg)$ - [F,NC,L]

location ~* \.(jpg|jpeg|png|gif|webp)$ {
valid_referers none blocked yourdomain.com www.yourdomain.com;
if ($invalid_referer) { return 403; }
}

In Cloudflare Dashboard, go to Scrape Shield → Hotlink Protection and toggle it on. This is the easiest one-click solution.

Never redirect to a user-supplied URL without validation. In PHP:
$allowed_hosts = ['yourdomain.com', 'www.yourdomain.com'];
$url = $_GET['redirect'] ?? '/';
$parsed = parse_url($url);
if (isset($parsed['host']) && !in_array($parsed['host'], $allowed_hosts)) {
$url = '/';
}
header('Location: ' . $url);

For login redirects, use relative paths like /dashboard rather than full URLs. Strip any http:// or https:// prefix before redirecting.

WordPress uses redirect_to in login forms. Wordfence and Solid Security validate this parameter. Ensure you're running a modern version of these plugins.

Add to your .htaccess:
<Files ".env">
  Order allow,deny
  Deny from all
</Files>

Add to your server block:
location ~ /\.env {
  deny all;
  return 404;
}

The safest approach is to move your .env file one level above your public web root (e.g., /var/www/.env instead of /var/www/html/.env). Update your app to read it from that path.

Assume all secrets in the file are compromised. Rotate: database password, API keys, JWT secrets, and any third-party service tokens immediately. Update your firewall to revoke old access.

Add to your .htaccess:
RedirectMatch 404 /\.git
Or:
<DirectoryMatch "^\.git">
  Deny from all
</DirectoryMatch>

location ~ /\.git {
  deny all;
  return 404;
}

The git repository directory should not exist in your production webroot at all. Use a deployment tool (Deployer, Envoyer, CI/CD pipeline) that copies only production files — without the .git folder.

Run git log --all --full-history and tools like truffleHog or git-secrets to find any credentials ever committed to the repo. Rotate anything found.

Use FTP or SSH to remove the file: rm /var/www/html/wp-config.php.bak. Check for any other variants: ls /var/www/html/wp-config*.

<FilesMatch "wp-config\.php\.(bak|old|copy|orig|tmp|~)$">
  Deny from all
</FilesMatch>

Assume the database password and WordPress secret keys have been seen. Change your MySQL password, update wp-config.php with the new password, and regenerate your WordPress secret keys at WordPress secret key API.

Delete all .sql, .zip, .tar.gz backup files from your public web directory. Run: find /var/www/html -name "*.sql" -o -name "*backup*" -o -name "*dump*" | xargs rm.

Always save backups to a directory that is NOT served by your web server. For example: /var/backups/ or a private S3 bucket with no public ACL.

Add to Apache .htaccess:
<FilesMatch "\.(sql|bak|backup|dump|db)$">
  Order allow,deny
  Deny from all
</FilesMatch>

Assume the dump has been downloaded. Change your database password and update wp-config.php. Force-reset all admin accounts in WordPress.

Remove phpinfo.php and info.php from your webroot: rm /var/www/html/phpinfo.php

Nginx: location ~ /(phpinfo|info)\.php { deny all; return 404; }
Apache: <Files "phpinfo.php"> Deny from all </Files>

Add to your .htaccess:
<Files "debug.log">
  Order allow,deny
  Deny from all
</Files>

In wp-config.php, ensure:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

If you need debug logging, move it outside the webroot:
define('WP_DEBUG_LOG', '/var/log/wordpress-debug.log');

<Files "install.php">
  Order allow,deny
  Deny from all
</Files>

Restrict /wp-admin/ access to your IP address using your security plugin, or in .htaccess:
<Directory "/wp-admin">
  Order Deny,Allow
  Deny from all
  Allow from YOUR.IP.HERE
</Directory>

Via FTP or SSH, delete .DS_Store from any public web directory. Check recursively: find /var/www/html -name ".DS_Store" -type f -delete

<Files ".DS_Store">
Order allow,deny
Deny from all
</Files>

location ~ /\.DS_Store {
deny all;
return 404;
}

Configure your deployment process (rsync, Git, FTP client) to exclude dot-files. In rsync: rsync --exclude=".DS_Store". In Git: add .DS_Store to your global ~/.gitignore.

The cleanest fix is to keep composer.json, composer.lock, and the vendor/ directory one level above your public web root so they're never web-accessible.

<Files "composer.json">
Order allow,deny
Deny from all
</Files>
<Files "composer.lock">
Order allow,deny
Deny from all
</Files>

location ~* composer\.(json|lock)$ {
deny all;
return 404;
}

<Files "package.json">
Order allow,deny
Deny from all
</Files>
<Files "package-lock.json">
Order allow,deny
Deny from all
</Files>

location ~* package(-lock)?\.json$ {
deny all;
return 404;
}

Configure your build process so that package.json and node_modules/ stay in your build directory, not in the public web root. Only ship compiled/bundled assets.

In your Nginx config:
location ~ /\. {
deny all;
return 404;
}
This blocks all dot-files and dot-directories from being served.

Apache natively blocks .htaccess by default. Confirm via AllowOverride None in the global config and no override for <Files ".ht*">.

Check curl -I https://yourdomain.com/.htaccess, /.htpasswd, and /.env — all should return 403 or 404.

Search for them: find /var/www/html -name "*.swp" -o -name "*~" -o -name "*.tmp" | xargs ls -la
Delete found files: find /var/www/html -name "*.swp" -o -name "*~" -delete

<FilesMatch "(\.(swp|swo|bak|orig|tmp)|~)$">
Deny from all
</FilesMatch>

location ~* (\.(swp|swo|bak|orig|tmp)|~)$ {
deny all;
return 404;
}

In Vim, add to ~/.vimrc: set directory=$HOME/.vim/swaps// to store swap files in a non-webroot directory.

Delete adminer.php, phpmyadmin/, or similar directories from your public webroot. Database management should never be done from a public URL on production.

In Apache .htaccess:
<Files "adminer.php">
Order Deny,Allow
Deny from all
Allow from YOUR.OFFICE.IP
</Files>

The secure way to manage databases remotely is SSH port forwarding: ssh -L 3306:127.0.0.1:3306 user@yourserver, then connect via TablePlus, Sequel Pro, or DBeaver on 127.0.0.1:3306.

The correct location for log files is outside the public directory, such as /var/log/apache2/, /var/log/nginx/, or /var/log/app-name/. Update your app config to write logs there.

<FilesMatch "\.(log|txt)$">
Order allow,deny
Deny from all
</FilesMatch>
Be careful not to block legitimate .txt files if your site needs them — use specific filenames instead.

location ~* \.(log)$ {
deny all;
return 404;
}

Install Wordfence Security (free) or run a scan via Sucuri SiteCheck (sucuri.net/website-scanner). These tools identify modified files and malware injections.

Download your current site files and compare them against a clean WordPress installation and your last known-good backup using diff -r /clean/ /infected/ or a tool like WinMerge.

Run via SSH: find /var/www/html -name "*.php" -newer /var/www/html/wp-config.php -type f to find files modified after your last clean install.

After identifying the injected files, restore from a verified clean backup. Then: update all plugins/themes/core, change all passwords, and remove unused plugins. Contact your host to request a server-level malware scan.

Use browser DevTools (F12) → Elements to find the hidden iframe. Note the src URL. Search your theme files and database for this string: grep -r "iframe" /var/www/html/wp-content/ | grep -i "display:none\|width=0"

Run this WP-CLI command to search your database:
wp db query "SELECT ID,post_title FROM wp_posts WHERE post_content LIKE '%iframe%';"
Also check widget options and theme mods.

Use Wordfence or Sucuri to perform a full file and database scan. These tools identify injected content in both files and the WordPress database.

Restore affected theme/plugin files from clean backups. Change your WordPress admin password, database password, and all API keys. Update all plugins and themes.

Search your theme files and plugins:
grep -r "script src" /var/www/html/wp-content/ | grep -v "cdnjs\|jquery\|googleapis\|cloudflare"
Also check the database: wp option get widget_text

Delete or clean the file containing the injected script. If it's in a plugin or theme file that should not contain that URL, restore from a clean backup.

A CSP header explicitly whitelists which domains can load scripts on your site. Any unwhitelisted external script will be blocked by the browser. See the CSP solution guide in this knowledge base.

Search your database for spam content:
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%viagra%' OR post_content LIKE '%casino%';"
Also check footer widgets and theme options.

SEO spam is usually inserted by a PHP backdoor. Run: find /var/www/html -name "*.php" | xargs grep -l "base64_decode\|eval\|gzuncompress" to find suspicious files.

After cleaning, submit your site for a Manual Actions review in Google Search Console. This lifts any spam penalties and restores rankings.

Search your theme and plugin files:
grep -r "http-equiv" /var/www/html --include="*.php" -l
Also check header.php, functions.php, and any recently modified files.

The redirect may be stored in WordPress options. Use WP-CLI to search:
wp db query "SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%http-equiv%';"
Or use the Better Search Replace plugin to scan all tables.

Delete the <meta http-equiv="refresh"> line from whichever file or database row contains it. The redirect is a symptom — run Wordfence or Sucuri SiteCheck to find the root compromise, then rotate all credentials.

Enable maintenance mode or add deny from all to your .htaccess to protect visitors while you clean.

Notify your host immediately. Many hosts offer emergency malware removal. Request a server-level scan and check for other compromised accounts on the same server.

If you have a pre-infection backup (via UpdraftPlus, BlogVault, or your host), restore it. Verify the backup is clean before restoring.

After restoring: change all passwords (WordPress admin, database, FTP, hosting panel), update all plugins/themes/core, install a WAF (Cloudflare or Sucuri), and enable two-factor authentication on admin accounts.

If possible, take the site offline or restrict access. The attacker may have persistent access and could be monitoring their shell. Take a snapshot/backup of the compromised state for forensics before making changes.

Run: find /var/www/html -name "*.php" | xargs grep -l "system\|exec\|passthru\|shell_exec\|base64_decode" | grep -v "wp-includes\|wp-admin"
Also check: find /tmp /var/tmp -name "*.php"

In php.ini:
disable_functions = system,exec,passthru,shell_exec,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
Restart PHP-FPM or Apache.

Add to .htaccess inside /wp-content/uploads/:
<Files *.php>
Deny from all
</Files>
This prevents uploaded PHP webshells from executing.

Search your WordPress files and database:
grep -r "coinhive\|cryptoloot\|minero\|coin-hive\|cryptonight" /var/www/html
Also check: wp db query "SELECT * FROM wp_options WHERE option_value LIKE '%coinhive%';"

A cryptominer implies full site compromise. Follow the known malware signature remediation steps: isolate, scan, restore from clean backup, rotate all credentials, update everything.

A strong Content Security Policy prevents unauthorized scripts from loading. Block all unknown domains in script-src to prevent re-injection even if the backdoor persists.

View page source and search for patterns like API keys: grep -r "api_key\|apikey\|secret_key\|access_token\|AUTH_TOKEN" /var/www/html/wp-content/themes/ --include="*.js" --include="*.php"

API calls involving secret keys should be made server-side (PHP), not client-side (JavaScript). Pass only the minimum required public identifier to the front-end (e.g., a Stripe publishable key is OK; a Stripe secret key is never sent to the browser).

Log into each affected third-party service (Google Maps, Stripe, Twilio, etc.) and revoke/regenerate the exposed API key. Update your server configuration with the new key. Apply IP restrictions or referer restrictions on the new key where possible.

Log into your DNS provider and add a CAA record:
yourdomain.com. CAA 0 issue "letsencrypt.org"
Replace with your CA (e.g., digicert.com, sectigo.com).

Add a second record:
yourdomain.com. CAA 0 issuewild "letsencrypt.org"

Most registrars (Cloudflare, Namecheap, GoDaddy) offer DNSSEC in their DNS settings panel. Enable it with one click — they handle the key generation automatically.

If you use a separate DNS provider (e.g., Route 53, Cloudflare), enable DNSSEC there first, then add the DS record at your registrar.

Log into your hosting control panel (cPanel, Cloudflare, etc.) and check if an IPv6 address is assigned to your server. Many shared hosts now provide one by default.

In your DNS manager, add a new record:
Type: AAAA, Name: @ (and www), Value: your server's IPv6 address.

Use ipv6-test.com to confirm your site is reachable over IPv6 after DNS propagation.

In BIND (named.conf):
zone "yourdomain.com" {
type master;
allow-transfer { none; };
};
For Cloudflare or Route53 users, zone transfers are disabled by default.

Cloudflare, AWS Route53, and Google Cloud DNS all block AXFR by default and offer DDoS-resilient anycast DNS as a bonus.

Test: dig @ns1.yourdomain.com yourdomain.com AXFR
You should see Transfer failed or REFUSED, not a list of records.

Audit your DNS for CNAME records pointing to: *.github.io, *.herokuapp.com, *.s3.amazonaws.com, *.netlify.app, *.azurewebsites.net. For each, verify the target is still claimed and active.

Log into your DNS provider and delete any CNAME records pointing to decommissioned services. If you no longer use a subdomain at all, delete the entire record.

If you still use the service, re-provision it (e.g., re-create the Heroku app or GitHub Pages repo) and verify the CNAME target is properly claimed before anyone else does.

PTR records are controlled by the IP owner (your hosting provider), not your domain registrar. Log a support ticket asking them to set a reverse DNS record for your IP pointing to mail.yourdomain.com or yourdomain.com.

In DigitalOcean: Droplet Settings → Edit. In Linode: Linodes → Network → Reverse DNS. In AWS: submit a request via the EC2 console → Elastic IPs → Actions → Update Reverse DNS.

The hostname in your PTR record must have an A record pointing back to the same IP. Mismatched forward/reverse DNS is itself a spam signal. Verify: dig -x YOUR.SERVER.IP and dig A the-hostname-returned.

Your email host (e.g., Google Workspace, Microsoft 365) provides an SPF include string. For Google: include:_spf.google.com. For M365: include:spf.protection.outlook.com.

Go to your DNS provider and add a TXT record for @ (root domain):
v=spf1 include:_spf.google.com -all
The -all means hard fail — reject anything not listed.

SPF records support max 10 DNS lookups. If you use many services, flatten the record using SPF Surveyor.

Add a TXT record for _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
This collects reports without blocking anything yet.

After reviewing reports for 2–4 weeks, upgrade to p=quarantine (spam folder), then p=reject (block completely).

Services like DMARC Analyzer, Postmark, or Dmarcian parse your reports and show you which sending sources fail.

Google Workspace: Admin console → Apps → Gmail → Authenticate Email. Microsoft 365: Security → Policies → DKIM. Both generate a key and give you a DNS record to add.

Your provider will give you a TXT record for selector._domainkey.yourdomain.com. Add it in your DNS panel and wait up to 48h for propagation.

Host a file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 86400

Add a TXT record: _mta-sts.yourdomain.com → v=STSv1; id=20240101000000Z
Update the id whenever you change the policy.

BIMI requires an enforced DMARC policy. Set p=quarantine or p=reject in your _dmarc TXT record before proceeding.

Create a square SVG of your logo in SVG Tiny 1.2 format. Host it at a public HTTPS URL on your domain, e.g., https://yourdomain.com/logo_bimi.svg.

Add a TXT record for default._bimi.yourdomain.com:
v=BIMI1; l=https://yourdomain.com/logo_bimi.svg;
For Gmail verified checkmarks, you also need a VMC (Verified Mark Certificate) from Entrust or DigiCert.

Add a TXT record for _smtp._tls.yourdomain.com:
v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com
Replace the email with one you monitor. Reports are sent in JSON format daily.

Services like Mailhardener or Dmarcian accept and parse TLS-RPT reports alongside DMARC reports, giving you a unified dashboard.

Install Two Factor (by the WordPress core team) from the plugin repository. It supports TOTP (Google Authenticator, Authy), FIDO2 security keys, email codes, and backup codes.

Solid Security Pro lets you require 2FA for specific user roles and refuse login until 2FA is configured. Under Security → User Security → Two-Factor, set Requirement to Administrator.

After installing, go to Users → Your Profile → Two-Factor Options. Enable "Time Based One-Time Password (TOTP)", scan the QR code with Google Authenticator or Authy, and save your backup codes in a secure location.

In cPanel, go to FTP Accounts → Configure FTP Client and switch to SFTP. In your FTP client (FileZilla, Cyberduck), change port 21 (FTP) to port 22 (SFTP).

Block the port at the firewall level:
sudo ufw deny 21
Or in your cloud provider's security group/firewall rules, remove the inbound rule for port 21.

sudo systemctl stop telnet
sudo systemctl disable telnet
sudo apt remove telnetd -y

sudo ufw deny 23

Edit /etc/mysql/mysql.conf.d/mysqld.cnf and set:
bind-address = 127.0.0.1
Restart: sudo systemctl restart mysql

sudo ufw deny 3306
In your cloud firewall/security group, remove any inbound rule allowing port 3306 from 0.0.0.0/0.

Edit /etc/redis/redis.conf:
bind 127.0.0.1
Restart: sudo systemctl restart redis

In redis.conf:
requirepass YOUR_STRONG_PASSWORD_HERE

sudo ufw deny 6379

Edit /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Restart: sudo systemctl restart sshd

Set Port 2222 (or any non-standard port) in sshd_config. This stops most automated scans, though security-by-obscurity is not a substitute for proper config.

sudo apt install fail2ban — automatically bans IPs after repeated failed login attempts.

Edit /etc/mongod.conf:
net:
bindIp: 127.0.0.1
Restart: sudo systemctl restart mongod

In mongod.conf:
security:
authorization: enabled
Create a dedicated user with minimum required permissions.

sudo ufw deny 27017
Or use your cloud provider's security group / firewall rules to block 27017 from all external IPs.

Edit postgresql.conf (find it with sudo -u postgres psql -c "SHOW config_file;"):
listen_addresses = 'localhost'
Restart: sudo systemctl restart postgresql

Edit pg_hba.conf and ensure no entries allow connections from 0.0.0.0/0. Use 127.0.0.1/32 for local connections only.

sudo ufw deny 5432 — apply immediately regardless of app config, as a second layer.

SSH into the server and run: sudo ss -tlnp | grep 8080 or sudo lsof -i :8080 to identify the process.

If it's a dev server, stop it: sudo systemctl stop <service-name> and disable it: sudo systemctl disable <service-name>

If the service must run, restrict it: sudo ufw allow from YOUR.OFFICE.IP to any port 8080
Then sudo ufw deny 8080 to block all other IPs.

Run: sudo ss -tlnp | grep 8443 to see what process is listening.

If it's a control panel (Plesk, cPanel, Webmin), ensure it uses a valid TLS certificate, has 2FA enabled, and IP allowlisting configured.

sudo ufw allow from YOUR.OFFICE.IP to any port 8443
sudo ufw deny 8443
This limits the panel to known office IPs only.

Run sudo ss -tlnp | grep 25. If you are not running a mail server, identify and stop the service.

sudo ufw deny 25. Most cloud providers (AWS, GCP, Azure) block port 25 by default on new instances — verify this in your security group or firewall rules.

Configure Postfix or Sendmail to only relay from authenticated users or localhost. In Postfix main.cf:
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject

Edit /etc/memcached.conf and set:
-l 127.0.0.1
Restart: sudo systemctl restart memcached

sudo ufw deny 11211
Also block UDP 11211 specifically since DDoS amplification uses UDP:
sudo ufw deny proto udp to any port 11211

If Memcached must be accessible on a private network, compile with SASL support and require authentication. However, binding to localhost is always the preferred approach for single-server setups.

Edit /etc/elasticsearch/elasticsearch.yml:
network.host: 127.0.0.1
Restart: sudo systemctl restart elasticsearch

In elasticsearch.yml:
xpack.security.enabled: true
Then run: bin/elasticsearch-setup-passwords auto to generate passwords for all built-in users.

sudo ufw deny 9200
Also block 9300 (Elasticsearch cluster transport port):
sudo ufw deny 9300

Immediately block the port: sudo ufw deny 2375. If you need remote Docker access, use SSH tunneling instead: ssh -L 2375:localhost:2375 user@yourserver then set DOCKER_HOST=tcp://localhost:2375.

Edit /etc/docker/daemon.json to remove any "hosts": ["tcp://0.0.0.0:2375"] entry. The daemon should only listen on the Unix socket at unix:///var/run/docker.sock.

Configure Docker with TLS client certificates on port 2376. Generate certs with: openssl or Docker's built-in tools. Never use port 2375 (unauthenticated) in any environment.

In your cloud firewall / Windows Firewall, remove the inbound rule for TCP 3389 from 0.0.0.0/0. Add an allow rule for only your specific static IP address.

Set up a VPN (WireGuard, OpenVPN, or your cloud provider's VPN) and connect to the server over VPN. RDP should only be accessible on the internal VPN network, never directly from the internet.

On Windows: System Properties → Remote → Allow connections only from computers running Remote Desktop with Network Level Authentication. NLA requires credentials before the session is established.

If you need XML-RPC for Jetpack, block only the multicall method that enables amplification:
add_filter('xmlrpc_methods', function($methods) {
unset($methods['system.multicall']);
unset($methods['pingback.ping']);
return $methods;
});

Remove the header that advertises pingback capability:
add_filter('wp_headers', function($headers) {
unset($headers['X-Pingback']);
return $headers;
});

In Cloudflare WAF, create a custom rule: if URI Path equals /xmlrpc.php AND Request Method equals POST AND IP is not your trusted IP → Block.