Security
- Directory Listing on /uploads/: Accidental Exposure If /wp-content/uploads/ shows a file index, you have exposed backups, internal docs and files that were never meant to be public.
- HSTS: enforcing HTTPS at the browser level in WordPress HSTS tells the browser never to request the site over HTTP again. An essential layer beyond the standard redirect.
- Mixed content on an HTTPS site: detect and clean unencrypted links An HTTPS page loading an HTTP resource is flagged as insecure, hurting UX and SEO. A guide to find and fix.
- WP_DEBUG in production: why it is dangerous and what to use instead Debug mode in production exposes file paths, versions and code internals to every visitor. Safe disable with private logging preserved.
- WordPress XML-RPC: A Legacy Interface Almost No One Needs XML-RPC exposes the site to brute force, pingback DDoS amplification, and ongoing CVEs. Disable it without breaking Jetpack.
- xmlrpc.php Still Reachable: Server-Level Blocking Is Mandatory Disabling XML-RPC inside WordPress is not enough while the file still responds. Only a server-level block truly closes it.
- No HTTPS: Why It Fails Even When You "Have Nothing to Protect" A site over HTTP is flagged "not secure", loses search ranking and leaks sessions. Migrate to HTTPS without breaking content.
- Session Cookie Flags: Secure, HttpOnly, SameSite Without these three flags, an admin session can be hijacked via XSS, HTTP sniffing, or CSRF. Configure them correctly.
- Brute-force protection for WordPress: three essential layers Without brute-force protection, a WordPress site faces thousands of login attempts per minute. Build a multi-layer defence step by step.
- Hiding the WordPress Version: Why It Helps and Why It Is Not Enough WordPress leaks its version in several places. Hiding it reduces bot noise but is no substitute for actually updating.
- Hiding the WordPress login URL: when it helps and when it does not Replacing /wp-login.php with a random slug drops 99% of log noise. A complementary layer to strong passwords and 2FA.
- wp-config.php permissions: why 600 or 640, never more wp-config.php holds your database password and secret keys. Permissions that are too open turn it into attack material.
- Blocking /wp-admin/install.php on a live WordPress site install.php is used once during initial setup. Leaving it reachable exposes the site to future vulnerabilities.
- Public REST API User Endpoint: Username Enumeration via /wp-json/wp/v2/users The /wp-json/wp/v2/users endpoint leaks usernames to unauthenticated visitors. Block it without breaking the site.
- HTTP Security Headers: Cheap Defense Against XSS, Clickjacking and MIME Attacks X-Frame-Options, X-Content-Type-Options, Referrer-Policy, CSP — four headers that block a long list of client-side attacks.
- How many WordPress administrator accounts should your site really have Every admin account is an attack vector. A complete guide to trimming admin counts without disrupting day-to-day work.
- Enforcing HTTPS site-wide: from installed certificate to full enforcement An installed certificate alone is not enough. Force HTTPS with 301 redirects, database link rewrites and mixed-content cleanup.
- Password policy in WordPress: why the strength meter is not enough WordPress shows a strength meter but does not enforce - users can tick 'confirm weak password'. Real enforcement, step by step.
- User Enumeration via ?author=N: Username Discovery Visiting /?author=1 triggers a redirect that exposes the login slug. Block it without breaking author archives.
- WordPress Salts: Why to Rotate Them and When Salts encrypt every session cookie. Rotating them logs out every user and revokes access for any compromised session.
- The 'admin' username problem in WordPress and how to remove it safely The username 'admin' is half the work for an attacker. Replace it with a safe administrator without losing any content.
- Recently Created Administrators: A Compromise Indicator A new admin you did not create is a red flag. Verify, revoke, and close the door behind the attacker.
- WordPress Core Update: Why You Should Not Postpone Even One Day Minor updates are security fixes. Major updates need planning. How to ship both without breaking the site.
- WordPress automatic updates: what to enable and what to keep manual Automatic security updates close vulnerabilities without relying on you. A guide to configuring core, plugins and themes the right way.
- The WordPress file editor: why to disable it before it is too late The built-in theme and plugin editor turns any admin compromise into full code injection. Two lines disable it.
- PHP Files Inside wp-content/uploads: A Hack Indicator and How to Clean Up Finding PHP files inside wp-content/uploads almost always means a webshell was uploaded. Here is how to detect, remove and prevent it.
- Sensitive files exposed at the WordPress root: .git, .env, wp-config.bak A .git folder, .env file or wp-config backup reachable via the browser leaks every secret on the site. How to detect and block.
- WordPress database prefix: why to change from wp_ and how to do it safely The default wp_ prefix makes SQL-injection exploitation easier. A safe procedure to change it without breaking the site.
- WordPress core file integrity: detecting malicious modifications A core file that differs from the official release is a strong breach indicator. Guide to detection, comparison and safe restoration.
- Vulnerable Plugins: Detection, Updating and Replacement A plugin with a known CVE is an open door for attackers. Detect, patch, and replace plugins safely when no fix exists.
- SSL Certificate Approaching Expiry: Renew Without Downtime An expired certificate fully blocks the site. Start renewal at least seven days before — never on the last day.