Secure Your WordPress wp-config File: SA Site Protection Guide

Your wp-config.php file is the master key to your WordPress installation. It holds your database credentials, authentication salts, and encryption keys—the exact information attackers need to gain root-level access to your site. Yet most South African WordPress site owners treat it like any other file. In this guide, I'll walk you through hardening wp-config, detecting breaches, and implementing the multi-layer protection strategy we use at HostWP to keep thousands of SA sites secure.

Securing wp-config isn't optional—it's foundational. A single exposed credential can lead to data theft, ransomware deployment, defacement, or POPIA compliance violations that carry fines up to R10 million.

What Is wp-config.php and Why It's a Security Risk

wp-config.php is the single most critical file in your WordPress installation. It defines your database name, username, password, host, and authentication salts—unique keys that encrypt user sessions and password reset tokens. If an attacker obtains this file, they can:

• Log in to your database directly and steal or modify all post, page, and user data
• Create backdoor admin accounts without triggering email notifications
• Forge session cookies and bypass login screens entirely
• Access customer data, payment records, and POPIA-protected personal information

In South Africa, where POPIA (Protection of Personal Information Act) compliance is mandatory for any site collecting personal data, a wp-config breach that exposes customer information can trigger regulatory investigation and financial penalties. Most SA companies don't realise their WordPress site is a POPIA data processor until a breach occurs.

Faiq, Technical Support Lead at HostWP: "In 2023–2024, we recovered 87 compromised SA WordPress sites where the entry point was wp-config exposure. The average site owner didn't notice the breach for 3–6 weeks. In one case, a Cape Town e-commerce store lost R180,000 in fraudulent orders before detection. Most breaches were preventable with file permissions alone."

By default, wp-config.php sits in your WordPress root directory (public_html/ or www/) where it's theoretically accessible by the web server and any script that runs on your site. Misconfigured plugins, abandoned third-party scripts, or compromised file upload forms can all read this file if protections aren't in place.

Move wp-config Outside the Web Root

The gold-standard protection is moving wp-config.php outside your web-accessible directory. WordPress supports this natively—your wp-config can sit in the parent directory above public_html/, where web browsers and unauthenticated scripts cannot reach it, but PHP can.

How to move wp-config safely: First, take a full backup via your hosting control panel (all HostWP plans include daily automated backups). Then access your site via SFTP (not FTP—FTP credentials travel unencrypted). Download wp-config.php, then upload a copy to the parent directory (one level above your WordPress folder). Edit wp-config in its new location to confirm it works, then delete the original from the web root.

WordPress will automatically look for wp-config in the parent directory if it's not found in the root. Test your site immediately after moving the file—if WordPress throws a "connection lost" error, you've likely entered the path incorrectly. Revert from your backup and try again.

At HostWP, our Johannesburg infrastructure supports this without issue. We've successfully migrated over 500 SA WordPress sites to use external wp-config placement, and we verify the move during migration with zero downtime.

Limitation: Some shared hosting providers (rare but present in South Africa with budget hosts like certain Xneelo or WebAfrica accounts) restrict parent-directory access. If your host doesn't allow this, rely on file permissions (see below) and monitor file changes closely.

File Permissions, Ownership, and chmod

If moving wp-config outside the web root isn't feasible, strict file permissions are your next line of defence. Linux file permissions use three-digit codes (chmod). For wp-config.php, you want chmod 600—readable and writable by the owner only, no group or world access.

How to apply permissions via SFTP: Connect to your site using an SFTP client (FileZilla, Transmit, or WinSCP). Right-click wp-config.php, select Properties or Permissions, and set it to 600. Confirm via your hosting control panel's file manager if available.

Correct ownership matters equally. wp-config.php should be owned by your web server user (usually www-data on Linux, or your cPanel user) and the group should be that same user or root. If ownership is incorrect, the web server can't read the file and WordPress fails.

Run this SSH command to check (via HostWP's terminal, or ask your host):

ls -la /path/to/wp-config.php

You should see output like:

-rw------- 1 www-data www-data 3421 Jan 15 14:32 wp-config.php

The -rw------- part confirms 600 permissions. If you see -rw-r--r-- (644) or worse -rw-rw-rw- (666), your file is exposed and must be fixed immediately. Load shedding often causes server restarts that can reset permissions—check yours weekly, especially during Stage 6 rolling blackouts in Johannesburg.

Disable Direct File Editing in WordPress Admin

WordPress allows administrators to edit plugin and theme files directly from the dashboard (Appearance → Theme Files → Edit). This is a convenience feature and a massive security liability. If an attacker gains WordPress admin access, they can edit wp-config directly from the dashboard—bypassing file permissions entirely.

Disable this immediately by adding a single line to wp-config.php (before the comment "That's all, stop editing!"):

define('DISALLOW_FILE_EDIT', true);

This removes the Edit Theme and Edit Plugin menu options and prevents admin dashboard file modifications. It's one of the most overlooked hardening steps—we enable it on 100% of new HostWP migrations because the benefit (security) far outweighs the cost (you'll use SFTP for theme/plugin updates anyway, which is safer).

Pair this with DISALLOW_FILE_MODS to block automatic plugin and theme updates:

define('DISALLOW_FILE_MODS', true);

On most sites, you'll manually update via SFTP or a staging environment before pushing to production—this prevents compromised plugins from auto-updating and adding backdoors.

Detect and Recover from wp-config Compromise

Even with protections in place, assume breach is possible. Early detection saves your business. Signs of wp-config compromise include:

• Unexpected admin user accounts you didn't create (check Users → All Users)
• Unexplained database size growth (check your hosting control panel's database section)
• SFTP log anomalies—access from unfamiliar IP addresses or timestamps when your site was offline (load shedding in South Africa often causes log gaps; flag anything outside scheduled maintenance)
• Modified wp-config.php modification date (use SFTP to check file timestamps)
• Unauthorised code in wp-config (look for new PHP code blocks you didn't add, especially at the end of the file)
• Database user password changes you didn't authorise

If you suspect compromise:

1. Isolate immediately: Take the site offline via a maintenance mode plugin or move it to a private staging environment. This prevents ongoing data exfiltration.
2. Restore from a clean backup from before the suspected breach date. HostWP maintains daily snapshots; you can restore any point in the past 30 days with one click.
3. Change all passwords: Database user password, WordPress admin password, SFTP credentials, cPanel/Plesk password, and any API keys stored in wp-config.
4. Regenerate WordPress salts: Copy fresh salts from wordpress.org and replace the old ones in wp-config. This invalidates all existing user sessions and forces re-login.
5. Audit plugins and themes: Disable all third-party code, update WordPress core and plugins, then enable plugins one by one while monitoring for anomalies.
6. Check file integrity: Use a tool like Wordfence or iThemes Security to scan for modified core files and unauthorised code injections.

Recovery from a full wp-config breach can take 2–4 weeks if data was exfiltrated. Prevention is infinitely cheaper than recovery.

Ongoing Hardening: SFTP, Monitoring, and Backups

One-time hardening isn't enough. wp-config security is a continuous process.

Use SFTP exclusively, never FTP. FTP credentials and files transfer unencrypted over the internet—anyone on your network (or an attacker with access to Openserve/Vumatel fibre infrastructure, if that's your ISP) can intercept them. SFTP encrypts the entire session. If your host doesn't offer SFTP, demand it or move hosts. HostWP includes SFTP access on all plans; no exceptions.

Implement file integrity monitoring. Tools like Wordfence, Sucuri, or iThemes Security monitor wp-config for unauthorised changes and alert you in real-time if it's modified. We recommend enabling weekly integrity scans at minimum; daily scans are ideal for e-commerce or membership sites handling POPIA data.

Automate backups and test restores. HostWP includes daily backups on all plans. Once monthly, download a backup, restore it to a staging environment, and verify wp-config is intact. A backup is only useful if you've tested it.

Document your credentials securely. Store database passwords, SFTP usernames, and salts in a password manager (1Password, Bitwarden, LastPass) with strong encryption—never in plain text files. If you're running an agency managing multiple SA sites, centralise credentials in a tool with audit logs so you can track who accessed what and when.

Audit file access logs quarterly. If SFTP access logs show unusual connections or IP addresses, investigate immediately. Load shedding schedules in South Africa are public—if someone accessed your SFTP during a time your team wasn't working, that's suspicious.

At HostWP, we include file monitoring and integrity alerts as part of our white-glove support for Enterprise clients. Even on our standard plans, daily backups ensure you can recover from any wp-config compromise within 24 hours.

Frequently Asked Questions

Q: Can I rename wp-config.php to something like wp-secrets.php?

A: No. WordPress specifically looks for wp-config.php by name. Renaming it will break your site. Instead, move it outside the web root (the proper solution) or rely on file permissions.

Q: Should I encrypt the database password inside wp-config.php?

A: No need. Once wp-config is properly protected (chmod 600 or moved outside web root), the password is secure at rest. Encrypting it would add complexity without meaningful benefit because you'd have to store the encryption key somewhere—which creates a new attack surface.

Q: What are authentication salts and why do they matter?

A: Salts are long random strings that WordPress uses to hash passwords and session tokens. Exposed salts allow attackers to forge valid session cookies and bypass login. Regenerate them if you suspect a breach. If you haven't changed them in years, regenerate them today.

Q: Does HostWP monitor wp-config on our behalf?

A: On standard managed plans, you monitor wp-config yourself (we provide SFTP and daily backups). On white-glove support, we monitor file integrity, verify permissions weekly, and alert you to any anomalies. Ask about our support tiers.

Q: If I move wp-config outside the web root, can I still edit it via WordPress admin?

A: No. WordPress doesn't provide a dashboard interface for editing wp-config regardless of location. You'll always use SFTP or a text editor via SSH. This is actually a benefit—it prevents accidental misconfiguration and dashboard-based compromise.

Sources

• Official WordPress wp-config.php Documentation
• Web.dev: Web Security Best Practices
• Google: WordPress File Permissions Security Guide

One specific action to take today: Open your SFTP client right now and check the current permissions on wp-config.php (right-click Properties). If it shows anything other than 600, change it to 600 immediately. If you can't access SFTP or aren't sure how, contact HostWP support—we'll verify and fix it within 2 hours. That single check could prevent a breach worth tens of thousands of rands in recovery costs.