Best-Practices for Directory

WordPress is installed as it is within the publicly accessible directory of the hosting. It does not provide for any part of the WordPress core to be stored in a non-publicly accessible directory. You can easily test this by installing WordPress in your directory.

According to your request, you would have to secure access to the wp-config.php (the only configuration file of WordPress) via your .htaccess. WordPress does not intend to store the file anywhere else. The WordPress core only generates log files if they are explicitly activated in debug mode. There are some plugins that write their own log files, which you would have to check separately.

Which basically means, by default wordpress doesn’t store sensetive files outside of the web root. Instead, it stores everything at public accessible directory but restrict access to sensetive – core files via htaccess, Kindly confirm if, this is the default practices? *So that i can confirm if this is how wordpress ecosystem works or it is due to my origin host environment.

My current setup works as such, but somehow i am looking into strengthening the directory aspect which consists of accessibility, permissions and also reachability. As accessibility and permissions are restricted as per how it should, here it comes the reachability [As quiestioned] aspect:

I was looking at the default practice which restricts via htaccessand i found there is a risk of relying on htaccess solely as in any event [rare occurrence] if the htaccess gets overwritten or corrupted, it might impose a risk or a damage. Therefore, instead of relying on the htaccess solely, i thought of conducting any each out of both below:

Option 1 : Isolation of Sensetive Files and Folders – moving out sensetive and core files and folders from the Public Accessible Directory.

Option 2 : Default with Double Layer – Maintain Existing Restriction Ruleset in htaccess + Block access to those sensetive paths in the first line of defense WAF Infrastructure. In any event of anything goes wrong with the htaccess it would still not be accessible publicly due to there is already a blockage [403] before the request can even reach the origin [Nature of First Line Defense].

Well, i am not an expert here but trying to improve the security posture specifically for this directory aspect as i could see a loophole [I Guess?] as described above.

Opinions and Suggestions are Welcomed and Highly Appreciated.

Instead, it stores everything at public accessible directory but restrict access to sensetive – core files via htaccess, Kindly confirm if, this is the default practices? *So that i can confirm if this is how wordpress ecosystem works or it is due to my origin host environment.

Yes, you can say it like that. WordPress only comes with a minimal .htaccess file. You can test this by installing WordPress locally away from your hosting environment, for example.

If you want to further secure access, you can proceed as you have already considered with your own lines in the .htaccess. This article should also give you some pointers: https://www.ads-software.com/documentation/article/hardening-wordpress/

Also bear in mind that there are web servers that are not Apache-based. The .htaccess file is only interpreted for these and only with the corresponding setting in Apache. These are tasks that WordPress cannot perform but must be carried out by the hosting support.

@threadi i think you misunderstood the options that i figured out which i am seeking for a recommendation as above.

Referring to my Option 2, Instead of seeking to strengthen htaccess which by default had been done, i am looking forward to implement additional layer to restrict direct access to the sensetive paths from the First Line/Layer of Defense where it could be such as Cloudflare WAF etc to block access to those sensetive paths before the request even reaches the origin.

I’ve did throughout checks to attempt direct access to sensetive paths and it returns as restricted [403 – Forbidden] which means it is not accessible as how it should be, and, the article that you shared had been referred a few days back as well and my current ruleset in htaccess seem to comply with what is there in the article. But then, the option 2 is basically a double layer to complement the existing htaccess based restrictions so that in any circumstance if the default origin based ruleset as set in htaccess goes wrong [rare occurrence – overwritten, corrupted etc], the access to those sensetive paths remains restricted especially if the incident involving the htaccess is unrealised.

In conclusion, maintaining the htaccess with all required lines + imposing additional restrictions [Rulesets that are more aggresive and different in pattern] before the htaccess so that if any one out of the both layers managed to be bypassed in direct access attempts, the other layer is there to avoid the revealance -consequently the damage. The primary focus and intention of this is to better protect sensetive paths rather than solely relying on htaccess itself.

If placing all files under public accessible area is the only way to go which means my option 1 is less suitable to be conducted, then I am looking into to conduct this as per my option 2. I’m looking forward for suggestion if option 1 or 2 would be a better option to go for.