Let's say that a partner wants to upload a PHP script to my Apache server. What kind of mayhem could be caused by this?

Which PHP parameters pose threats? If those PHP parameters are fully disabled, would allowing PHP to be inserted on my servers then be safe?

These are some PHP parameters that I know of that pose a security flaw. What others are there that are unsafe?

Writing to server:

  1. fwrite

  2. file_get_contents


Opening files on server:

  1. fopen

  2. file_get_contents

  3. include

  4. fread

  5. url_get_contents

  6. curl_init

  7. curl_setopt

Deleting files:

  1. unlink
  2. unset

Are there any other security flaws that I should be thinking about before allowing partners to add .php files onto my server? I imagine that there might be a lot that I'm unaware of.

I'm also worried about loop scripts that could use up all of my RAM and CPU, backdoor access attacks, malware and the like. Are there any measures that I can take to prevent any of that and more from happening?

If there is Javascript, JQuery or other languages embedded in the PHP script, are those dangerous as well? And what kind of parameters in other languages would I need to disable in order to protect my server?

How do websites like jsfiddle and codepen keep their sites secure while allowing people to post their own code?

migrated from webmasters.stackexchange.com Mar 21 '18 at 13:43

This question came from our site for pro webmasters.

  • 5
    A sandbox might help. See Is there a PHP Sandbox, something like JSFiddle is to JS? and Google PHP sandbox. – Neil Smithline Mar 21 '18 at 14:00
  • 5
    What is your use case? Do you want their PHP to become part of your site? – Neil Smithline Mar 21 '18 at 14:02
  • 31
    Just to be clear, you intend to execute the PHP? Not just let people download it as code? – Anders Mar 21 '18 at 14:21
  • 4
    I'm not a PHP sandbox expert, but I don't think that any sandbox provides 100% security. But they try. So this is a low-risk, but not no-risk strategy. – Neil Smithline Mar 21 '18 at 17:01
  • 2
    It sounds like you want the code to actually run, and provide some part of the functionality of your site, in which case sandboxing (even if you could guarantee it) isn't going to help since it's trying to avoid just that. If this is that kind of collaborative development you'd deal with that as part of your deployment process - that's a different scenario to providing a means for people to upload code to your site and execute it – Mohirl Mar 21 '18 at 17:46

It's very dangerous, because you are allowing to someone to upload PHP file with unknown code and unknown intentions, so if you need this functionality as part of your web site, you should harden your server, for example:

  • Set a only one directory to upload PHP files from users, you should apply right user permissions (read, write or execution) for this directory, remember create a specific user for this directory, not use root user.
  • You can create a .htaccess file for directory, then you could set specific settings for that directory (Configuring .htaccess file).
  • Validate input user, even you should set a specific name format and size maximum for PHP files, if a PHP file doesn't match with that format or its size is bigger than what is allowed then application shouldn´t allow to user to upload that file.
  • Use canonicalization before use file functions, for example: realpath, basename. This helps you to avoid path traversal attack.
  • You should disable PHP functions with high risk, for example: exec, shell_exec. You can do this through php.ini file, for example, you could add the following line helps to disable functions for OS command execution and settings management:


    The following line helps to disable functions for include or open files from external sources:


Official documentation php.ini file

Those are some basic recommendations. You should analyze your web application and your needs to set the right settings for your server and web application.

I hope this information helps you.

  • 4
    Set a only one directory to upload PHP files from users - Shouldn't this be one directory per user. (So each external user has one specific directory and one specific local user that runs code from this directory) – Taemyr Mar 21 '18 at 16:57
  • @Taemyr you are right, it could be another security level. – hmrojas.p Mar 21 '18 at 17:47
  • 31
    That you spend over 95% of this answer explaining how to try to secure the server disturbs me immensely. It should be the other way around: spend 95% of the answer discouraging it and 5% talking about what you can do. – jpmc26 Mar 21 '18 at 21:19
  • 7
    @jpmc26 Ok, I understand your point because it's a dangerous topic, for this reason I said "If you need this funcionality ..." before to explain my recommendations, now those are only recommendations, he can decide to follow them or not, also this site is about security and how to solve this kind of problems, not avoid them, so users of this site are professionals and they sometimes have to try to solve problems before to decide not continue with a solution, for those reasons I considered to give some recommendations, but I respect your point. – hmrojas.p Mar 21 '18 at 22:26
  • 11
    @hmrojas.p "This site is about security and how to solve this kind of problems, not avoid them." I patently disagree. Very often the only sane answer in security is, "Don't do that." And also very often, if you have to ask whether something widely known to be dangerous is a risk, you simply do not have the knowledge to try to defend from it, nor is the time and money spent trying to defend from it a good investment. – jpmc26 Mar 23 '18 at 1:57

If you allow somebody to upload and execute a PHP script on your server, you effectively give this person the right to do whatever he or she could do, if she had ssh access with username/password for process the PHP script runs as.

So, if the person in question would run the script through Apache, the person could do anything the Apache user on your server could do.

As an additional risk, this person could use the given access to try privilege escalation, something that would probably break the legal agreement you have with them (you do have a legal agreement, don't you?).

  • 40
    PHP is a programming language that enables programming. So if I create mycmd='c'+'a'+'t'+' ''+'>'+'/'+'e'+'t'+'c'+'/'+... what are you going to grep for? If I get more complex... The simple answer is there is no simple way to run untrusted code safely. – Adam Shostack Mar 21 '18 at 15:39
  • 11
    @Taemyr: PHP has several ways of executing functions dynamically, e.g. php.net/manual/en/functions.variable-functions.php – poizan42 Mar 21 '18 at 16:57
  • 31
    @Taemyr I look forward to watching you make a fortune with your awesome new static analysis tool which makes this safe. – Adam Shostack Mar 21 '18 at 17:02
  • 12
    @Taemyr, that might work in a sensible language, but this is PHP we're talking about. – Mark Mar 21 '18 at 23:45
  • 13
    @Michaeld, blacklisting is not a solution that works, there are way too many options to bypass blacklists; this is a fact that has been shown way too many times. Whitelisting in this case only works if you can guarantee that you are smarter that the combined knowledge of all people that may use your system. – Jacco Mar 22 '18 at 7:48

To me it sounds like you are about to shoot yourself in the foot. Letting people you don't trust upload and run PHP on your server is extremely dangerous. Here are some things an attacker could try:

  • Run batch commands taking over your webserver. It can then be used as a staging ground to attack other servers from within your network.
  • Read files containing secrets, e.g. passwords, encryption keys, TLS keys, etc.
  • Do XSS attacks (using JavaScript) to steal session cookies or other credentials from your users. This is assuming the uploaded files run on the same domain or a subdomain as other applications.

The list goes on and on and on. There are ways you could try to block these attacks (hmrojas.p has some suggestions), but that is no simple thing to do. Blacklisting functions is a start, but blacklisting is never more than a partial defense. Even for the best of experts, containing someone who can run PHP is a challenge.

In the end, if you don't trust the person who wrote the code you will have to carefully and manually audit the code to make sure it is benign. That takes time and effort, and it isn't compatible with direct file upload.

Sometimes, the only winning move is not to play. I'd say this is one of these cases.

  • 1
    I think I know what you mean here but trusting code doesn't make it safe. Sorry to be pedantic but I've seen people get confused by things like this and do the opposite of what they should do. – JimmyJames Mar 22 '18 at 15:54
  • @JimmyJames Obviously trust can be misplaced, and obviously there can still be mistakes. But by definition, if your trust is well placed, there are no deliberate issues with the code. I'll try to edit to make it clearer. – Anders Mar 22 '18 at 16:18
  • 1
    I guess what I am trying to say is a trust relationship should be considered a significant risk. You are not only assuming that the trusted party will be non-nefarious but also that they have adequate security and protect their credentials. It also creates opportunities for third parties to subvert that trust relationship via flaws. Your edit seems to address this. – JimmyJames Mar 23 '18 at 16:50

While there are sites that allow you to run PHP code on demand (i.e. 3v4l), they severely limit what you can do and jump through some major hoops to do it safely

I use a setup where scripts are executed in a small virtual machine. For security reasons this machine has no network and only a minimal filesystem. Scripts are executed by a daemon (written in Golang) and results (with statistics) are reported to a PostgreSQL database. All results are stored and used to provide averages for the performance overview.

I would not allow users to upload PHP scripts in a live environment. We once had an intern who was writing an image upload script. Except he forgot to validate anything about the file he was accepting. Someone uploaded a PHP malware script from Turkey and attempted to take it over (he would have gotten away with it too had it not been for other security efforts on the server).


PHP has a lot of functions to disable features and restrict certain actions so it can be used in shared hosting scenarios. So it is much safer to allow people to upload php scripts than i.e. perl scripts, when your webserver and php instance are configured correctly.

So I want to address another thing than the security of urlopen and similar: You are allowing people to run interactive sites.

The consequences are dangerous independend from how much network or disk IO they can make, because they can for example setup a phishing site, which can reflect badly on your domain and IP reputation.

So you do not end up on a blacklist because of spam mails as they are blocked by disallowing php to send mail, but possibly because you're running a script which phishes for user's facebook logins.


You mention an Apache server, but not whether or not it has PHP installed.

Either piece of software can be used/installed without the other.

Both pieces of software are available for multiple operating systems.. you haven't mentioned which is in play here.

In the case that PHP is installed on the server:

The risk is that, should the user account PHP ends up running under, have administrative rights to the machine, they can do anything in the PHP library.

Should that account not have administrative rights, this restricts what they can do.

Some operating systems have discoverable/known exploits allowing non-administrative accounts to 'get' administrative rights. These are known as privilege escalation exploits. If one is used, then again.. they can do anything in the PHP library.

In the case that PHP is not installed on the server:

There's little to no risk at all. A PHP file is just a text file of instructions that PHP interprets and acts on. It's no more harmful than a text file with a recipe for stew.


There is no way you can “secure” this. Any amount of allowing someone/anyone to execute code at will on a system can lead to complete system takeover, either inherently due to executing all instructions of due to defects in the system that is trying to prevent certain functions from being used.

Even a scripting language in a jail/chroot/container as a dedicated user can ultimately exploit vulnerabilities (existing/new ones) that allows for full root access and more (i.e. firmware access). This is what shared hosting providers have to deal with all day long. Most of the prevention and fixing comes from two things:

  1. Legal; list what they can and cannot do in a contract ahead of time

  2. Process; have redundancies and recovery schemes in place do deal with breaches/loss


Yeah, you're going to want to sandbox this. Probably the simplest way to do that is with execution in a VM or docker container. Of course, then you'll need to audit the security around that.

  • 4
    No that's wrong. It is possible to escape a Docker container, there are documented exploits for this (some harder than others, but here we are). Considering that the Docker daemon runs as root, trusting Docker to keep the malicious code contained seems ill-advised. In the end, jailing the untrusted code (even by virtualisation) doesn't matter much when you must also protect the services inside that same jail. – korrigan Mar 22 '18 at 17:04
  • @korrigan When you say "services [in the] same jail" do you mean services within the very same sandbox, or other services on the same host machine? My assumption is that there is no protection of things that are together in the same sandbox. – Marcin Mar 23 '18 at 19:22
  • From OP's comment: The PHP is intended to run on the site.. Yes I meant in the same sandbox (or jail). Your assumption is right in this regard. – korrigan Mar 23 '18 at 19:31
  • @korrigan Obviously. You'd want to separate serving from running here. E.g. have the php server running in the vm, and the rest of the site running outside of that jail. – Marcin Mar 23 '18 at 19:32

Your Answer

