The only real security problem is that if the file isn't parsed and it's in 
the web server's document path, somebody can just go to and see the entire contents in 
plaintext -- passwords and config options galore. However, sticking those 
.inc files outside of the web server's document path or otherwise cutting 
off access to those files makes things a lot safer. 

When I met Rasmus at a seminar a few months ago, he mentioned that he kind 
of started the whole ".inc" thing with included files, but he was 
astonished how so many people followed his convention without realizing 
that somebody could look into the .inc file so easily. When he was going 
it, he always explicitly denied access to those files through a <Files> 
directive in Apache's httpd.conf file, which nobody else bothered to do.

So if you want people to view those files and all of the code in them, go 
nuts. Otherwise, you'd better somehow cut off access to them. (Personally, 
I use an include directory and use a .htaccess file to limit access.)


Erik Price wrote:

> On Friday, February 15, 2002, at 10:50  AM, Michael Kimsal wrote:
> Maybe I don't understand the security implications of .inc -- I thought
> that it was perfectly safe.  Since my php.ini is not configured to parse
> files with '.inc' extensions, I thought that I was better off using a
> separate extension than '.php': so that the code cannot be "executed out
> of context".  I got this idea from a post by Rasmus Lerdorf on this very
> list, only a month ago.
> Erik

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to