For required/included files in PHP, is it better to use .inc
extensions vs .inc.php
vs .php
extensions?
views:
62answers:
3Sometimes people use the .inc
extension and then do some server configuration to keep .inc
files from being accessed via a web browser. This might be good, if done absolutely correctly by a knowledgeable sysadmin, but there's a better way: Any file that's not supposed to be accessed by web users should be kept outside your document root. Once these files are off the web, so to speak, you can use whatever extension you want. .php
is definitely a sensible choice for syntax highlighting, general sanity, and so on.
My personal preference is that anything in the document root is a .php file, to indicate it's directly executable by the web server, and anything that's a library is a .inc file stored in a parallel directory, to indicate it's NOT directly executable.
My standard configuration is
/home/sites/example.com/html/
- anything here is 'safe' to expose if PHP fails and serves up raw code
/home/sites/example.com/inc/
- libraries, config files with passwords (e.g. the database connection class with DB credentials), etc.. Anything that shouldn't be exposed as there's no reason for it.
While you can certainly configure Apache to deny access to .inc files and keep them inside the webroot, then you're depending on Apache to keep you safe. If PHP can fail within Apache and expose your code, then the .inc blocks can ALSO fail and expose your code's innards as well.
Of course, if Apache's coughing blood all over the floor, there's no reason that the directory traversal protection can't fail as well and let someone do http://example.com/../inc/seekritpasswords.txt.
At some point you just have to accept that if something's stored anywhere on the web server, there's a possibility that a failure may allow access to the raw data and expose everything. How much time and effort you want to expend on protecting against that is up to you.