Probably a dumb question...

the hardening doc suggests setting up your web server so that it prevents access to wp-config.php. If you do this, and a client tries to access the file, Apache returns 403 Forbidden, as expected.

If you don't do this, Apache returns 200 Ok with an empty file. This is also as expected, because none of the php code in this file produces any output.

So what's the point? Surely this would only be an issue if the attacker had already broken in, and turned off php support?

  • The link you provided explains everything and also points to other resources that give a more detailed answer Apr 13, 2022 at 14:11
  • @Buttered_Toast - I've been through the doc several times, and I'm pretty sure that this is never mentioned.
    – QF0
    Apr 13, 2022 at 14:31
  • Really, the first this is saw was this wordpress.stackexchange.com/questions/58391/… Apr 13, 2022 at 20:14

1 Answer 1


So what's the point? Surely this would only be an issue if the attacker had already broken in, and turned off php support?

If an attacker has already done this then this particular hardening is pointless. An attacker is unlikely to turn off PHP execution though as that would require more effort and would actually be harder for no gain. It would also make it very obvious you'd been hacked.

Generally, wp-config.php contains secrets so this adds an additional layer of security. There is no specific thing it prevents, much like how adding an third wall around a castle doesn't convey any protection the second wall doesn't, it just adds extra obstacles.

Try not to think of things as "secure" or "not secure", that's not how website security works. In the same way that your site is neither "hard" or "soft", you can make it harder, or more secure though.

What's more likely is that while poking around in the server, you make a silly typo or mistake that lists all PHP files as plaintext, so an attack goes to wp-config.php to read your database details but gets a forbidden HTTP code back instead. But the chances of this are incredibly slim.

  • Well... if your system setup is such that your site isn't serving php, then it's completely obvious, and you wouldn't go live. If it is serving php, then there appears to be no way that wp-config can be leaked through the web server. Fixing something that ain't broke requires more code, more documentation to make sure that others understand what you've done and why you've done it, reduces Apache performance because it has to check all requests against this file, and also introduces the possibility of breaking something else.
    – QF0
    Apr 13, 2022 at 14:41
  • @QF0 Your assumptions are partly wrong. See this answer for an example how easy you can get misconfigured/missing PHP. Did you check NIST or other authorities, what they recommend to do with configuration files in publicly accessible directories?
    – kero
    Apr 13, 2022 at 14:48
  • Thx - those answers go through pretty much everything. IMHO, though, the accepted one is entirely wrong. His fundamental problem was that someone else configured his system (Plesk), and he didn't test his own change, which is bizarre. The error must have been obvious, but he didn't spot it for 3 weeks. He's in no position to give lectures on site security. However, at least 3 people point out that configuration changes on shared sites can lead to php being turned off, which is a good point, and someone points out a (very old) php bug which led to php files being listed. TBC...
    – QF0
    Apr 13, 2022 at 19:54
  • ...but no-one pointed out that Apache can easily serve files outside DOCUMENT_ROOT. In my case, I'm 100% responsible for site configuration on a root-access VPS, so the only real issues are bugs in Apache, php, and WordPress. Given this, I think I'm probably slightly in favour of disabling access in the Apache conf file, but moving wp-config does seem pointless. Can't upvote you, so I'll accept your answer, with these caveats... :)
    – QF0
    Apr 13, 2022 at 19:59
  • 1
    the hardening doc is a generic document aimed at helping as many people as possible, with a huge variance in technical skill in experience, it isn't intended to be a comprehensive nuanced specific article. The person reading it may be a veteran IT administrator, a chip designer, a 15 year old setting up their first website, a gardener who wants to sell their services, etc. Keep that in mind when reading the document, and also keep in mind that security can be layered. "Shouldn't be possible" is a dirty word, why not make it "can't" be possible? Multiple protections!
    – Tom J Nowell
    Apr 14, 2022 at 9:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.