Geek Answers Handbook

Why is placing the framework under an open root safer?

Why is it always recommended to place the framework files outside the public root?

Given that sometimes the framework does not have .ini or .inc files that can be opened by the browser.

+4
source share
3 answers

Well, definitely nothing will come of placing the resources of the framework inside the web root. Since the choice of where to place the file is free, it is logical to follow the principle of least privilege: you do not need web access to these files, so you will not get it.

A more specific reason is that database sources can easily disclose the brand and version of the structure used on the website (although this information can also be obtained by examining the generated content); this in turn will make it easier for attackers to exploit known or recently discovered vulnerabilities.

+7
source

This is safer because if the web server has an incorrect configuration, it is possible that the script files (be it .php, .asp or something else) can be spat out in text form, and a potential attacker will see all your source code and certain passwords. Therefore, it is best to place only the index.php file in webroot, which, in turn, includes loading the script from outside webroot.

I remember one example in the real world - in Latvia, where I live, we have a large social network "draugiem.lv" (in our country more popular than Facebook), and several years ago all of their PHP source code was leaked by an incorrectly configured server as I described earlier.

+5
source

In addition to the main reasons mentioned in other answers: incorrect server configuration, principle of least privileges, etc. - It is worth noting that many frameworks, including the Zend Framework, can use configuration files that are in formats other than PHP, for example, .ini , .yml , etc.

If they were in a public web root, then - depending on the server configuration - they will be served directly to everyone who requests them. Since these configuration files usually contain confidential information such as db passwords, API keys, etc., of course, it is advisable to make them inaccessible as inaccessible.

As an example, consider application/configs/application.ini . If the doc root was at the project folder level, then the request for:

http://example.com/application/configs/application.ini

will deliver the keys to the lock.

+2
source

More articles:


All Articles