PHP architecture planning - hide your files

Data exposure in general includes globally available configuration files, cache files, log files, license and readme files, ability to call internal parts of the architecture in a way not designed to be called. 

Ability to call system internals can and will lead to serious security issues, for example, ability to call some management part of the system, and, for example, expose or even damage some data otherwise inaccessible by general public by implementing poor security techniques. 

Even publicly available readme files, packaging manager config files, license files and much much more such files can tell potential attacker sufficient amount of information to successfully violate some parts of the system, for example, using known vulnerabilities to open source software which is not properly updated or give ability to actually locate system internals. 

Lets think about very common scenario, a issue which can and will lead to serious security implications - use of front-side controllers in PHP web applications which directs routed calls to independent, mostly, standalone (MVC) controllers. Lets imagine our application have parts accessible by general public, and some - only after successful authentication, for example - web administration panel. Imagine Yourself a web developer, thinking - my panel is located in single request sub-directory of my URI, why should I implement security mechanisms in each and every controller, if I can implement it in a single place - router or dispatches, or whatever you would like to call it. Fine idea - administrative section is now protected, everything seems to be fine. One thing which is not fine, is URL rewriting condition met in almost all web platforms to date using front controllers - file availability check. Most such rewrites first checks if file exists, and if it doesn't - only then routes requests to front controllers thus making obvious public resources like images and stylesheet files publicly available. One thing that also becomes available to potential access violation is all Your system internals, because they simply exist and is available to general public, not even mentioning situations when in some poorly configured production systems there are global directory listings enabled.

Let's return to our sample system, where authentication subsystems are implemented not as part of controllers, but as part of routing. In this scenario, attacker can successfully gain access to "locked" controllers simply by calling them from publicly accessible location via URI, therefore giving attacker access to administrative part of the system. For example, http://example.com/admin/ could also be called via http://example.com/app/controllers/adminController.php

To be honest, chance to become a victim to such exploit is quite low only because such exploitation would require ridiculous amount of work from the attacker himself, and ridiculous lack of attention from the developer too. But it is possible, not only theoretically. 

All the exposure types mentioned earlier can be successfully avoided with ease - by moving Your web application root outside the application scope. Simple as that. This not only "hides" all the commonly met files - readme's, licenses, and other from public, but also helps to keep "the house clean". 

Lets take a sample where we use some PHP framework as a base for our application. Most of the open source frameworks uses front controller approach and routes all requests which can not be routed to file system to front controller file. 

Simplest way to move application outside public scope is to move front controller file and public assets to sub-directory of the system and then simply set the virtual hosts root to newly created subdirectory. This way we solve the information exposure problem without loosing our systems uniformity, where some parts of the system are located in different places. In situations where changing web servers options is not possible, for example, shared hosting with limited configuration options, You can reroute all requests to sub-directory using mod_rewrite and .htaccess of Apache server and then by placing second .htaccess in subdirectory to route all requests except existing assets to front controller. Even if You don't use Apache, this is still available with every web server software out there to date.

By moving applications public root "away" from the system itself we effectively make all the system resources unavailable via public web, therefore avoiding information exposure and other possible security issues.