I'm trying to figure the right security settings for the files on my shared webserver and I have a few basic questions that I've not figured out by looking around.

How do I stop people reading my PHP files. The recommended setting seems to be 644 which allows the whole world to read them. Is that right? Does the php suffix stop them?

If PHP script (executed by the client) within public_html is accessing a html file on the same server but above public_html, can I set that to 600 in that the script is effectively the user?

Is anything above public_html is hidden from the outside or is it just the permissions that do that?

Edit By client, I mean an iPhone app which calls a variety of PHP scripts. The content of the files is not super private - but I want to minimise the risk of hacking and so don't want people to easily be able to read scripts and other files.

Many thanks,


migrated from stackoverflow.com Jul 28 '11 at 2:28

This question came from our site for professional and enthusiast programmers.


It really depends on how people are accessing the scripts. Are you concerned that someone with SSH access is going to open your PHP files? Or are you just concerned that they are accessing scripts through the browser that you don't want them to run?

If it is the first concern then you need to talk to your host about account and group permissions. If it is the second concern then you can use .htaccess files to prevent access to files and entire directories. If you are worried that browser-based visitors will see your code then don't. The web server won't send the code to the end user.

Why would you put a php script up on a public site that you didn't want people to read? What are your concerns with it? If you only want certain people to be able to run a script then you need to add in a login system along with a permissions system.

Also, why would you want to use a method that involves two files when one would suffice. Your security for browser-based access won't come from file permissions. It will come from login and user permissions.

Your web server will not serve up anything from a directory it is not set to provide access to. Another words if your account has a public_html folder and a subdomains folder and both are configured for your website to serve sites and data from then those are the only locations it will come from. Web-based access is actually really straightforward. Your not accessing the file system. Your accessing what Apache is set to deliver to you. Your account directory can have other folders that contain whatever you want that will not be visible to the web. Just create the directory and don't point Apache at it.

  • When you say "someone with SSH access is going to open your PHP files" do you mean other people with accounts on the same shared host? So I think what you and others are saying is that if files are above public_html then they're private regardless of file permissions to all except those who have hosting accounts on the same shared host. Finally, does teh fact that a file has a .php suffix stop people reading it (i.e. viewing it rather than executing it)? – Chris Jul 27 '11 at 9:48
  • Actually what I am saying is that in a standard shared host that gives you SSH access you will only be able to see your account and its files from the SSH terminal window. Others will not be able to see this. – Patrick Jul 27 '11 at 16:48
  • Also I am saying that Apache will not serve up anything that is not in public_html. It just won't do that. Further, any languages it is configured to interpret will automatically be interpreted. So anyone coming in from a browser (through the Apache interface) will never see your code unless you intentionally expose your code. – Patrick Jul 27 '11 at 16:49
  • Some hosts might have problems with *.inc files and other files that contain php but don't have the extension. But this tends to be the exception rather than the rule. An easy way to test this is to try to go to some dummy files you have uploaded to your host and see what comes up. Do this through your browser (the tools that outsiders will have). – Patrick Jul 27 '11 at 16:51
  • Thanks @pthurmond. So essentially, all my files above public_html are safe and any files that end in .php below public_html will be interpreted (ie run) and not displayed for people to have a good look at. – Chris Jul 28 '11 at 10:17

If by "client" you mean, browser or something else which can send an HTTP request, then there is generally no worry. Apache will attempt to execute the file before it serves it which means that you're likely to get goblety-gook if you do a direct request against it. Of course, if you're able, it is often a good idea to make the base files of your application reside somewhere other than public_html/ and include them through relative paths. This is a good deal easier if you're using a framework instead of some home-brewed stuff, but it is still possible without a framework backing you up.

On the other hand, if by client you mean, "your company is hosting someone else's stuff", then you're talking about server stuff. The "user" who runs PHP files is usually Apache (HTTPD depending on your server configuration). While I believe it is possible to make it so that different scripts have different authorities with the same Apache server, you're better off creating a virtualized instance in a chroot jail


If your PHP files must be readable by the web server process, then they will be readable by anyone else possessing a website on the box. This is how most web hosts set up their boxes.

If asset protection is of the utmost importance, then go dedicated. An alternative is to have your web host implement some sort of user switching mod like suPHP. Only then can you set the php files to 600 and still have them work.

Bottom line, ask your host for available options.


On a properly configured web server everything above DocumentRoot is hidden from the outside world and that behavior is handled by the web server itself not the file-system permission system.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.