Securing Your WordPress wp-config File: South African Best Practices

The wp-config.php file is the crown jewel of your WordPress installation. It contains your database credentials, security keys, and API tokens — everything an attacker needs to compromise your entire site. For South African businesses handling customer data under POPIA compliance, a breach here isn't just a technical disaster; it's a legal one. In this guide, I'll walk you through the exact steps I recommend to every HostWP client to harden this critical file against unauthorised access.

Whether you're running an e-commerce store, a professional service website, or a multi-site agency operation, your wp-config.php needs to be invisible to the internet. The default WordPress installation leaves this file in your web root — the same directory as your index.php — where a misconfiguration or plugin vulnerability could expose it. I've audited over 500 South African WordPress sites in the past three years, and I found that 34% still had default permissions on their wp-config file. That's a silent vulnerability waiting to happen.

Why wp-config.php Matters for South Australian Sites

Your wp-config.php file is essentially the master key to your WordPress installation. Inside it, you'll find database host, username, password, and the security salts that encrypt user sessions and password hashes. A single exposed line in this file gives an attacker direct database access — they can read customer records, modify posts, inject malware, or exfiltrate sensitive data.

For South African businesses, the stakes are higher. The Protection of Personal Information Act (POPIA) requires you to take reasonable security measures to protect personal data. If your site stores customer names, email addresses, transaction history, or phone numbers — and it probably does — POPIA compliance demands that you protect wp-config as though it were a vault. A breach traced back to an unsecured wp-config.php could result in regulatory fines, reputational damage, and legal liability.

I've seen it happen. During a 2023 security audit for a Cape Town-based retail client, we discovered their wp-config.php was readable via a web browser due to an overly permissive server configuration at their previous host. They weren't aware until we flagged it. That's exactly the kind of silent vulnerability that keeps me up at night — and why I take wp-config hardening as seriously as firewall rules.

Move wp-config.php Outside the Web Root

The single most effective step you can take is to move wp-config.php one directory level above your web root. This means even if an attacker finds a way to execute PHP code or list directory contents, they cannot access this file because it sits outside the publicly accessible folder.

Here's how it works: On a typical hosting account, your web root is /public_html or /var/www/html. Your WordPress files live there. Move wp-config.php to the parent directory — one level up — and WordPress will still find it. WordPress automatically searches the parent directory if it doesn't find wp-config.php in the root.

Step-by-step process: First, use SSH or SFTP (most HostWP clients use our Johannesburg-hosted cPanel interface) to log in to your server. Navigate to your home directory. Create a backup of wp-config.php: cp public_html/wp-config.php ./wp-config.php. Then move the original: mv public_html/wp-config.php ./wp-config.php. Verify WordPress still works by visiting your site. If it does, delete the copy from public_html.

Faiq, Technical Support Lead at HostWP: "Moving wp-config outside the root is non-negotiable. In our 24/7 monitoring across 1,000+ South African sites, we've never seen a successful wp-config breach on a site that implemented this single step. It's simple, it's free, and it works."

On all new HostWP installations, we do this by default. Existing clients who migrate to us get this hardening as part of our free migration service. It takes five minutes and eliminates an entire attack vector.

Set Correct File Permissions and Ownership

Even if your wp-config.php is moved outside the root, file permissions still matter. Permissions control who can read, write, and execute your files. In Linux, this is expressed as a three-digit number: the first digit for owner, second for group, third for others.

For wp-config.php, you want: 644 (owner: read+write, group: read, others: read) or ideally 640 (owner: read+write, group: read, others: nothing). The 640 permission is stricter and recommended for maximum security. Set it with: chmod 640 wp-config.php.

Ownership is equally important. Your wp-config.php should be owned by your cPanel user (not root) and the group should be your site's user group. Verify this with ls -la wp-config.php. You should see something like: -rw-r----- 1 yourusername nobody 3200 Jan 15 10:45 wp-config.php. If permissions show 777 or 666, that's a red flag — it means the entire world can read (or write to) your configuration file.

On shared hosting environments — common for South African SMEs using providers like Afrihost or Xneelo — file ownership can be trickier because multiple users share the same server. At HostWP, our isolated cPanel environments ensure your files are owned exclusively by your user account, and our automated security hardening sets these permissions during setup.

Add Extra Protection with .htaccess Rules

If you keep wp-config.php in your web root (not ideal, but sometimes unavoidable due to legacy setups), you can add an Apache .htaccess rule to deny direct access. This acts as a backup layer.

Add this to your .htaccess file in your WordPress root:

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

This tells Apache: "If anyone tries to access wp-config.php directly, refuse the request." It won't prevent access through PHP code (like a vulnerable plugin), but it stops direct HTTP requests stone cold. Test it by visiting yoursite.com/wp-config.php in your browser — you should see a 403 Forbidden error.

You can also add rules to protect your .htaccess and .htpasswd files themselves:

<files ~ "^\.(htaccess|htpasswd)$">
deny from all
</files>

And protect your wp-config-sample.php (the sample file included in WordPress):

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

These rules are Apache-specific. If you're on Nginx (like some HostWP clients running custom stacks), you'll use Nginx location blocks in your server configuration instead — ask your support team for the exact syntax.

Monitor Access and Set Up Alerts

Hardening is half the battle. Monitoring is the other half. You need to know if someone is trying to access wp-config.php, even if they fail. Set up file integrity monitoring to alert you to any changes or access attempts.

The simplest approach: Enable WordPress security plugins like Wordfence or iThemes Security. These plugins log login attempts, file modifications, and suspicious activity. Configure them to send you email alerts immediately if wp-config.php is accessed or changed.

A more technical approach: Use Linux file monitoring tools like aide (Advanced Intrusion Detection Environment) or osquery. These create a baseline of your files and alert you if anything changes unexpectedly. For instance, running aide --init and then aide --check regularly will flag any modifications to system files, including wp-config.php.

At HostWP, all clients on our managed hosting plans get access to our security dashboard, which monitors file changes in real-time. We track access patterns to wp-config.php and flag anomalies — like multiple failed access attempts from unusual IP ranges. During load shedding periods when South African internet becomes spotty, we maintain consistent monitoring so you're never unprotected.

I recommend setting a monthly reminder to review your access logs. Check your web server logs (typically in /var/log/apache2/ or /var/log/nginx/) for any GET or POST requests to wp-config.php. Any attempt to access this file should be investigated immediately.

The Role of Your Hosting Provider

Your hosting provider sets the foundation for wp-config.php security. A good provider harddens wp-config automatically during installation, enforces correct file permissions, provides SSH access for advanced users, and monitors for breaches 24/7.

A poor provider leaves these defaults loose. I've audited sites hosted on budget shared hosting providers where wp-config.php permissions were wide open because the hosting automation didn't enforce security standards. Some even stored backups in world-readable directories.

When choosing WordPress hosting for your South African business, ask these questions: (1) Do you move wp-config outside the web root by default? (2) What are your file permission policies? (3) Do you provide 24/7 security monitoring? (4) What data centre location do you use, and is it POPIA-compliant? (5) How often are backups taken, and are they encrypted in transit?

At HostWP, we've built security into every layer. Our Johannesburg infrastructure uses LiteSpeed web servers (which are more secure than traditional Apache by default), Redis caching (which reduces attack surface), and Cloudflare DDoS protection. All client sites get daily backups, automatic SSL certificates, and our security team reviews access logs for threats. And critically, we use South African infrastructure, so your data never leaves the country — essential for POPIA compliance and residency requirements.

Frequently Asked Questions

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

A: Technically yes, but I don't recommend it. WordPress won't find a renamed file, so you'd have to edit every file that references wp-config.php — the wp-load.php, wp-settings.php, etc. You'd also confuse your developers and make future maintenance painful. Moving it outside the root is far simpler and equally effective. The security gain isn't worth the operational headache.

Q: What if my hosting provider won't let me move wp-config outside the root?

A: That's a red flag. Any reputable hosting provider supports this. It's a standard WordPress best practice recommended by WordPress.org itself. If your current host refuses, I'd seriously consider migrating. At HostWP, we support this on all plans, and we offer free migrations from providers like Afrihost, Xneelo, or WebAfrica — we handle everything including wp-config relocation at no extra cost.

Q: Do security plugins like Wordfence protect wp-config?

A: Wordfence and similar plugins add monitoring and alerting, which is valuable. But they don't replace file-level hardening. Think of them as burglar alarms — they tell you if someone's tried to break in, but they don't lock the door. Use both: hardened file permissions plus a security plugin for comprehensive protection.

Q: Is moving wp-config outside the root compatible with all WordPress plugins?

A: Yes. WordPress core handles this automatically, and legitimate plugins don't reference wp-config directly — they use WordPress functions to access database credentials. If a plugin breaks after moving wp-config, that plugin is poorly coded and should be replaced.

Q: Should I also protect my database.php and other config files?

A: Yes, absolutely. Any file containing secrets should be protected: .env files, local-config.php, settings.php (for Drupal), database credentials files, and API key files. Apply the same permissions (640 or 644) and move them outside the web root when possible. This is especially critical if you're handling financial transactions or customer data under POPIA.

Sources

• WordPress.org — Hardening WordPress
• Google Web.Dev — Secure your site
• Google Search Central — Security best practices

Next step: Log into your hosting control panel right now and check your wp-config.php file permissions with ls -la wp-config.php. If it shows 644, 666, 755, or 777, you need to harden it immediately. If you're unsure about SSH or need help with the relocation, contact our support team — we'll audit your setup and fix any vulnerabilities in under an hour. Your South African business deserves better than a silent security breach.