Where to place PHP files for security?

Question

A simple question, where do you place PHP files on a server? I can't seem to find any good information on this.

Obviously public files should be in the document root somewhere/somehow, since they need to be accessed, but what about the rest of the files, all the classes etc?

I am attempting to refactor a single page web app with a PHP backend, where most of the files are within the document root, but there are some sensitive files (with passwords etc) above the document root. I was trying to setup autoloading which led me to folder layout. This split layout feels quite messy, is there a better way to do it?

My thought is it should follow the principle of least privilege, if those files don't need to be public then they shouldn't be. Why is this something that is not right at the start of PHP the right way?

I'm using Apache here, it would seem Node is better in that everything is private unless you point your router at it. Is there is a standard way of handling this? If so how to implement it on apache?

Answer 1

Place your public files in a folder called public and point your domain name to this folder using apache virtual host, other non-public files should be in folders above the public folder and you can refer to them by include_path for example. This is how most frameworks are structured.

Answer 2

Where to place PHP files for security?

Put in mind that there is no best place to store your files safely. The safety of your sensible files is only a result of a combination of good measures -such as preventing URL injections that may disclose your sensitive files- you may take and discussed below briefly.

My thought is it should follow the principle of least privilege, if those files don't need to be public then they shouldn't be. Why is this something that is not right at the start of PHP the right way?

Same question you could ask about why firewalls are not recommended. But the answer is that because the article you choosed is rather intended for developers. Developers are more worried on how to to make it work than how to make it safe. Look to the sections discussed through that article:

Getting Started (general setup , PHP versions to choose ...), Code Style Guide (Programming Paradigms, Namespaces, Standard PHP Library, Xdebug ...), Dependency Management, PEAR (installation and so on), Coding Practices, Dependency Injection (a software design pattern), Interacting with databases, Templating ...

As you can guess, this is addressed for developers not for the ones who are worried like you by security aspects of an application. The only section that speaks a little bit about security is Security, and within it may be only the subsection related to password hashing, data filtering and sanitization are important but still poorly covered.

Is there is a standard way of handling this?

The article you linked to states: There is no canonical way to use PHP. Same thing we can say: There is no canonical way to use PHP safely. This is said, the principle of least privilege you mentioned is a must and still there are good safety practices you need to follow because only a conjunction of these principles all together can give you a better assurance:

1. Defense in depth: you must resolve your problem in terms of layers of security: secure setup of Apache, safe coding style, firewall, effective .htaccess files ... While some argue that this principle adds complexity to your application and may bring new security risks, a smart application of this principle can keep your application simple but safe (for example: hashing passords allowing access to your folders is good, but salting them is better, peppering them in addition is even better).

2. Specify folder and files whitelist: Instead of listing folders and files that must not be accessed, you need to rather authorize access to your public files/folders and reject everything else because this way you won't forget protecting some sensible files.

3. Least privilege: your resource permissions (files in your case, but you may consider other elements) must be granted at minimum level to users of your website
4. Do not rely that much on security through obscurity to hide your files.
5. Minimize the attack surface of your web application
6. Detect intrustions: log security relevant information to identify the risks and protect your application
7. Some think that a reputed hosting company is enough as an element to protect their application, but still you need to protect your application separately and independently from the hosting environment
8. Do not rely only on third party actors to secure your application

Answer 3

Basically you are right: on a server you own there is no actual need to place the PHP files in the document root directory. Only is needed some entry point like an index.php file or any other file targeted by your rewrite rules. Once the web-server hand-hovers the request processing to the PHP interpreter, you are not bound anymore by the web-server's DocumentRoot path but by the PHP interpreter's open_basedir path (which is not set by default, allowing the PHP interpretor to access files anywhere on your system).

However, such scenario requires two prerequisites:

• You own your own server: Most of shared environments impose some directory structure and system-wide configuration which may not be suitable for this kind of implementation. For instance you may not have access to directories above the DocumentRoot affected to you, or some restrictions might be applied in the PHP configuration.

• The web application you intends to use supports it: This may often be simply reworded in "You use your own web-application". Indeed, most projects are developed in way making them compatible with the widest possible range of users, and therefore impose as few prerequisites as possible.

  Therefore, most projects just consider the web application as a whole to be put under a single directory. This is easier to deploy and to maintain (on directory to update, no risk of update level discrepancy between several folders), and fits in about any situation whether your are using your own server or are renting a shared hosting space.

  Some projects could however propose the setup you describe as an option (using some kind of include_path setup parameter), however this might make the project more difficult to develop and maintain from a developer perspective (I mainly think here about qualification tests which would then have more situations to take into account) without providing any significant security benefits.

As said such measure would not bring any significant security benefit anyway since on a well configured server your PHP files content will never be disclosed by the web server: such files will be executed by the PHP interpretor and never sent as raw text files. The main threat is someone able to execute code on your server (for instance by installing a PHP shell) allowing him to wander over your directory tree, but in this case having the PHP files outside of your DocumentRoot directory will be of no help either).

The least privilege principle remains still true though, but it would merely concern the way the web server, the PHP interpretor and the PHP script files themselves interact together. For instance:

• Some implementation (a classical example being Nginx + PHP-FPM for instance) will allow you to use different users for the web server and for the PHP interpretor, letting you freely set which files and resources should be shared between these accounts or not.
• You may also want to ensure that the PHP files are only readable and not writeable by the user running the PHP interpretor, the PHP Suhosin patch even propose a parameter (suhosin.executor.include.allow_writable_files) preventing the execution of any PHP file not conforming with this criteria,
• PHP also offer the above mentioned open_basedir which prevents the PHP scripts from accessing any files located outside of some directories.
• Etc., etc., etc.: there can be many other way to implement the least privilege principle and to secure your web application platform, some being generic, some more specific to your platform and application.