Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If I have a php script that is reading / writing to a file, is it a security hole?

Essentially I have a form that is just saving and restoring data from a file so I don't have to deal with a database. This has worked great on my local dev machine and I was going to put it on a more public machine to share with a couple other people.

Is there any real security risk with just the file being writable by my php script?

share|improve this question
If it's possible that the reader could try to excute the data read(think SQL injection) then I'd say yes. But I'm don't know PHP well enough to say that's possible or not. – Robert Dec 14 '09 at 21:06
up vote 3 down vote accepted

If the name of the file isn't dependant on user input, then there is little risk. If it is, you have to make real sure that the user dependant part is well sanitized, by removing all potentially dangerous characters, such as ., / or .

Others have mentioned a possible DOS by filling up the disk; but you get that risk with a database, too.

There is then another risk, which is not a vulnerability in itself but could serve as one. The attacker could use that method to create content of his choosing on the server and use it to exploit a vulnerability by getting it executed. Most commonly, the problem present itself if you let the user create a .php file and let it be accessed through the server. The user just needs to open http://yourserver/uploads/hisupload.php to do what ever he wants.

The safest way to avoid this problem is to put all uploaded files outside the server directory. That means you must then serve the files through a php script of your own, not directly to the outside. Usually on Unix you have your php scripts unders /var/www/html. Just have you script write them under /var/www/uploads, for example, and there is no way for the web server to go there, unless you've done something stupid with your httpd.conf.

If you can't control this, then use a .htaccess to limit access to that particular directory, and/or make sure that the files cannot be executed as PHP or server-side includes (.shtml) by always appending a safe extension such as .html or .txt.

share|improve this answer

In addition the the DoS risk, you have to make sure that the content is sanitized so that when PHP reads it back out of the file, data doesn't get interpreted as code. One advantage of using SQL is that sanitizing SQL data is a fairly standard and well-understood process, whereas I'm not sure wha tthe state of the art is for PHP.

share|improve this answer

Beware of the potential for DoS from the respect of the script being able to fill the file system it has write access to.

share|improve this answer
Is there a way to limit that? – hortitude Dec 14 '09 at 21:10
The use of quotas on the account the PHP process runs as (same as the web httpd process, most likely). – Geoff Fritz Dec 14 '09 at 21:17

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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