Typically my job description limits me to code-review of web applications. More recently I've been asked to assist with some server-side PHP optimization where, although I am familiar with it, I lack experience.

I have come across a configuration setting called:


Are there any implications I should be aware of by utilizing this setting (other than the obvious function x() will be disabled and any application that uses function x() will then not work)?

If it is something I should be taking advantage of, I can come up with a list of many functions which could be dangerous, however some may be necessary regardless. Does anyone have a list, or have some suggestions to add as far as which functions should be disabled and why in case I miss/overlook some?

Any insight would be appreciated as although I know plenty of unsafe functions, my server configuration experience is lacking.

EDIT: To clear up any question as to whether this is on or off topic, I was asked to assist with OPTIMIZING the PHP enviroment for increased SECURITY, but I'm asking specifically about the aforementioned configuration setting. :)

  • Is this question about hardening PHP environment or only about disabling dangerous functions? From the beginning of question it looks like you were asked to increase overall security.
    – anonymous
    Commented Dec 29, 2010 at 21:01
  • See my edit for clarification
    – Purge
    Commented Dec 30, 2010 at 18:24
  • Well, then I would recommend also to edit title of this topic. Securing PHP environment is not only about disabling functions.
    – anonymous
    Commented Dec 30, 2010 at 18:49
  • I agree with your last sentence, however I'm not asking how to secure the PHP environment. I'm asking specifically about disabling the functions as a small part of an OVERALL process of securing the PHP environment.
    – Purge
    Commented Dec 30, 2010 at 19:17

7 Answers 7


There are a number of things that must be understood here:

  1. List of dangerous PHP functions is located here: http://php.net/manual . Seriously, almost any PHP function can be dangerous given the right context. strlen and like are probably safe, but any function that talks to outside world can brings surprises if the rest of the code is not safe.
  2. If you want to secure the site, the security should be throughout the code, just disabling some function here and there is not going to work, only going to blind you and lead to sloppy coding.
  3. There are capabilities in PHP that can assist you in writing more secure code, however they won't make secure code from insecure one. Look for open_basedir and allow_url_fopen as an example.
  4. You can use disable_functions to prohibit some actions that you consider dangerous, however only certain classes of actions can be inhibited this way. For example, you can disable exec,shell_exec,popen,passthru,proc_open,system,pcntl_exec and this probably will prevent running external programs from your code - but most of the things done by these programs can be done by PHP means too. And trying to avoid things like "writing a file" probably won't work - you should do it via OS permissions, not via PHP. So, define what exactly do you want to prohibit first and then see if it's possible - while keeping in mind it may be impossible.
  5. Read security chapter in the PHP manual. Read some PHP security books. Security is not done by just setting security=On in php.ini, unfortunately.

The only issues you have to worry about with this is disabling functions that are actually necessary. Disabling functions can definitely help prevent abuse. There are indeed functions such as exec, shell_exec, etc that should almost never be used in a shared hosting environment.

Rather then just relying on this function though, you should consider working on general security. For example, if you use suPHP or similar, you can prevent a whole bunch of attacks, and make securing things a bit easier. Disabling functions should be the last thing you worry about, your server should be secure before you worry about that.


If you are hosting a website or a web server then there are functions in PHP which can be use to exploit the web site or web server using PHP scripts and using this dangerous function hacker can get complete control over web server upto root level.

The List of Function dangerous in PHP development

"apache_child_terminate, apache_setenv, define_syslog_variables, escapeshellarg, escapeshellcmd, eval, exec, fp, fput, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, highlight_file, ini_alter, ini_get_all, ini_restore, inject_code, mysql_pconnect, openlog, passthru, php_uname, phpAds_remoteInfo, phpAds_XmlRpc, phpAds_xmlrpcDecode, phpAds_xmlrpcEncode, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, syslog, system, xmlrpc_entity_decode"

How to Disable dangerous functions in PHP

  1. Locate your "php.ini" file.

  2. then find disable_functions=

  3. then add all the above function in disable_functions like


^^ here i have disabled only 2 function you can disabled any numbers of function by giving list of function to disable_functions="list of function to be disable separated by comma"

If you want to what each above functions exactly mean search the above function here


  • 4
    "The List of Function dangerous in PHP development" - according to whom? Why? If I thought there was any benefit in disabling some functions (its arguable in some very obscure edge cases - but there's nothing in the original question to indicate these might apply) the list I'd come up with would look nothing like this.
    – symcbean
    Commented Dec 30, 2010 at 10:28
  • Note that disabling eval will break some existing software. It's better to leave it enabled, unless you like explaining to users why application X won't work on your server, but will work on everyone elses.
    – devicenull
    Commented Dec 30, 2010 at 14:00
  • 4
    First of all, eval() can't be disabled in such way, it is a language construct, not function. It can be disabled via Suhosin. Secondly, where did you get something like "inject_code"? What's that? Thirdly, why to disable escape[...]? Moreover, this list is not enough - how about sockets, dl(), others?
    – anonymous
    Commented Dec 30, 2010 at 14:15
  • 2
    IMHO this is an exercise in futility. If somebody gains access to your system allowing him to run arbitrary PHP code on your system, disabling functions not going to help. There are dozens on functions not listed which can be used this way. Actually, this list makes zero sense - mysql_pconnect is there but mysql_connect and mysqli_connect are not.
    – StasM
    Commented Dec 31, 2010 at 0:26
  • 2
    About this list of functions, and why I downvote: lucb1e.com/?p=post&id=86
    – Luc
    Commented Aug 10, 2012 at 18:00

Please do NOT consider disable_functions a security feature.

See my previous answer to a different question on stackoverflow - even PHP does not consider disable_functions and similar as a real security feature(s).


There are no inherently dangerous functions in PHP. OTOH it's remarkably easy to write very insecure programs just using the core functionality of PHP. IMHO, 'disable_function' is a placebo for people who can't/won't secure their systems properly.

Don't get me wrong - as a sys admin there are lots of other things you should be doing to secure your server - like setting open_basedir wherever possible, enforcing a strong permissions model, keeping include paths outside of the document root (or with direct HTTP access disabled fro those dirs) and lots more.

I've been asked to assist with some server-side PHP optimization

Are we talking about optimization or security here?

  • See my edit for clarification
    – Purge
    Commented Dec 30, 2010 at 18:24

While I haven't touched PHP in quite a few years, from what I've read


is most appropriate for shared hosting situations.


As of 2019, I have worked with a startup that was against creating a whitelist as they are starting out development, but wanted a blacklist. They required access to the filesystem and to the cURL library for the AWS SDK, but are using custom HTTP calls so can't rely on the SDK using socket streams.

Importantly this was far from the only technique utilised to secure the system. However, there are some scripts and techniques used that are often seen in various exploits/shells, so in a scenario where someone has managed to edit something they shouldn't be able to and you want to limit further damage, the list I used was:

disable_functions = apache_child_terminate,apache_setenv,chgrp,chmod,chown,curl_multi_exec,define_syslog_variables,eval,exec,highlight_file,openlog,parse_ini_file,parse_ini_string,passthru,php_uname,popen,posix_kill,posix_setpgid,posix_setsid,posix_setuid,proc_open,shell_exec,show_source,syslog,system

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .