I'm doing a redesign for a client who's understandably concerned about security after having been hacked in the past. I had initially suggested using a simple PHP include for header and footer templates and a contact form they wanted. They are reluctant because they were advised by their hosting company that using PHP is a security concern which might allow someone to break into cPanel and gain control of the site.

This, to me, sounds about like telling someone to never drive so they won't be in a car accident. My gut instinct is that the host is trying to shift blame onto the client for security flaws in their own system. Also, the server still has PHP installed, whether or not we use it, so I'm questioning how much this actually reduces the attack surface... But since I'm not a security expert, I don't want to stick my foot in my mouth.

I told my client that to process the contact form they're going to need some form of dynamic scripting. (False?) They asked if I could just use PHP on that one page. Would this be measurably safer, or is it the equivalent of locking your car doors and leaving the window rolled down?

How much truth is there to the claim that using any PHP script, no matter how simple, is an inherent security problem? We're on shared hosting with no SSL. Is it reasonable to assume we got hacked due to using PHP? Will we be any safer if we don't use it, but can't uninstall it? Because if not, we have other problems.

(Would the answer be different for any other language?)

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Jun 29, 2016 at 16:42

9 Answers 9


It's not so much that PHP itself has security problems (assuming needed security updates), as it is there exists a lot of popular PHP-based software with rampant security problems. You could fault PHP for being a language that gives you enough rope to choke yourself, but the real problem is just how prevalent vulnerable PHP code actually is. One need look no further than the Stack Overflow PHP tag to find PHP newbies writing horrifically vulnerable code based on some atrocity of an old tutorial.

Additionally, a significant number of popular PHP software known for their rampant security flaws is based on very old code and coding practices. Many of these old practices are considered bad-practices because of inherent security problems.

This, to me, sounds about like telling someone to never drive so they won't be in a car accident.

Pretty much yes. Better advice might be along the lines of "don't drive an old car with no airbags".

My gut instinct is that the host is trying to shift blame onto the client for security flaws in their own system.

Not necessarily. If a user uses the same password for the WordPress site and cPanel, compromising the WordPress password also compromises cPanel. That would be the fault of the user. Hackers rarely need to get that far though, and just use a PHP shell.

I told my client that to process the contact form they're going to need some form of dynamic scripting. (False?)

Not necessarily true. You could use a 3rd party service to handle the mail sending. Then the service handles the dynamic server scripting and take over the security implications. There are numerous such services available with varying feature sets, and they are popular for powering contact forms on statically generated sites.

How much truth is there to the claim that using any PHP script, no matter how simple, is an inherent security problem?

Some, but not much. PHP does involve some active code, in both PHP and the server software which executes it. If there were ever a security vulnerability in that process which did not depend on specific PHP code, it could be exploited. While that risk is tiny, it's a risk a server with no such support does not have.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Jul 1, 2016 at 11:26

"Right" might not be the right word, but "wise," "prudent" and "conscientious" come to mind. PHP has, since its inception, adhered to a philosophy that devalues correctness in software. There is a huge number of situations a program can encounter where other languages (e.g. Python) would give up and throw an error to tell you that your program is wrong, but PHP instead chooses to do something nonsensical and carry on as if things were just fine.

Keep in mind that correctness is very important to security. A language that is prone to silently ignoring errors left and right will have more than its fair share of programs with security problems. For example, you may have a piece of code that your programmers think is protecting against a certain attack, but in fact is being skipped because the interpreter ignores an error.

In addition:

  • PHP is designed to appeal to the lowest denominator of programmers with the least motivation to get good at their craft. And thus the most likely to write insecure software.
  • The PHP team has a history of profoundly flawed attempts at fixing common security problems. Look for example at SQL injection protection, which betrays repeated flawed attempts at fixing the problem: real_escape_string (because the original escape_string was broken, but they didn't remove it until later) vs. addslashes vs. mysql_escape_string/pg_escape_string and so on. Whereas pretty much every other language just went with prepared statements and query parameters and got a design extensible to all databases right on the first try.

So for all the talk in other answers about how you can write secure software in PHP, if you try it you're very much swimming against the current.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Jul 6, 2016 at 19:32

PHP's security problems can generally be narrowed down to two categories

Unpatched systems

As of right now, Wordpress stats shows over half of all users are running PHP on versions of PHP that are past End of Life (PHP 5.2 - 5.4). In two weeks, PHP 5.5 goes EOL and then it jumps to about 80% of all installs. Now, to be fair, some Enterprise/LTS Linux installs will backport security fixes, but the vast majority of them are not using backported fixes (or some don't patch their systems). Worse, lots of people refuse to upgrade PHP itself. Either they can't/won't update their code, or they think that older software is more stable.

Wordpress (#1 PHP application used worldwide) made a concerted effort to make sure users stay up to date on the software itself (and they've made great strides), but despite that, only 40% are running the latest version of Wordpress. That means some 60% may have an unpatched security vulnerability. And that's just the base program. Wordpress has a massive ecosystem of plugins, and many of them have security vulnerabilities of their own.

Then there's other issues, like lots of older code using the defunct mcrypt library. And that's just one PHP plugin you can compile.

Now extrapolate this to the servers not running and reporting stats to WP. It doesn't paint a pretty picture. Last summer I found a website running an e-commerce page that was still on Apache 1.3.3 and PHP 4.1.2. It was so old it had SSLv2 enabled...

Bad Practices

If you hang around SO PHP questions long enough, you'll see a lot of people practicing bad code. Some of the problems I've seen over the years

  • SQL Injection
  • Thinking MD5 is a good way to protect passwords
  • Using outdated APIs int their code (i.e. ext/mysql, the old MySQL connector)
  • Trusting user input to execute code (i.e. using eval with user supplied data)
  • Not turning off security risks in the PHP code (i.e. the exec function)

To the untrained, this looks like a PHP problem, when it's the coders and their ecosystems that produce the problems. Maybe they were in a hurry. Maybe they hired some guy who does this in his spare time and "just made it work".

Can it be secure?

YES! But that security requires some effort. Keep your PHP install up to date. Heck, keep your whole server up to date. Host won't do security and patches? Find another host. (I'm amazed at the people who balk at this). Build your own server (VMs are cheap). But above all, pay attention. Learn all you can about security. Don't just let your website and server go out to sea.

Someone who tells you PHP is insecure is just being lazy.

  • 22
    Build your own server (VMs are cheap). - Only do this if you know how to admin a Linux machine, or the administration is (competently) done for you. People having VMs with no clue how to make/keep them reasonaby secure is a significant problem in itself.
    – marcelm
    Commented Jun 28, 2016 at 20:15
  • 3
    @marcelm True, but at least you can work with your own VM, as opposed to a host that won't upgrade anything
    – Machavity
    Commented Jun 28, 2016 at 20:45
  • 15
    The idea that all languages are equal from a security perspective is just wrong. Saying you can fix the issues doesn't make it the same as a language that doesn't have them or requires you to actively introduce those issues.
    – JimmyJames
    Commented Jun 28, 2016 at 21:11
  • 13
    "Someone who tells you PHP is insecure is just being lazy." -> I totally agree with that!
    – Josip Ivic
    Commented Jun 29, 2016 at 9:30
  • 17
    "Someone who tells you PHP is insecure is just being lazy": Or is being realistic about the laziness that will happen. I mean, it's also possible to write a secure website in raw assembler, but realistically it's very likely not to happen.
    – ruakh
    Commented Jun 29, 2016 at 23:09

PHP is no less, or more secure, or insecure than any other language (Java, Rails, etc). It is all about the coding. Are checks and balances in place to deflect, defend, prevent, and or mitigate an attack. Quoting:

WhiteHat Security performed vulnerability assessments of more than 30,000 websites using .NET, Java, ASP, PHP, Cold Fusion and Perl. The most widely used languages were .NET (28.1 percent of Web applications), Java (24.9 percent) and ASP (15.9 percent).


The programming language .Net had an average of 11.36 vulnerabilities per slot, Java 11.32 and ASP 10.98. The most secure language, ColdFusion, had six vulnerabilities per slot. Perl had seven vulnerabilities per slot and PHP had 10.


Java accounted for 28 percent of vulnerabilities found and ASP 15 percent. “Again, the number of applications written in the language along with the complexities of the websites has to be considered as a contributing factor,” said the report. PHP also accounted for 15 percent of vulnerabilities discovered. ColdFusion only accounted for 4 percent of vulnerabilities and Perl 2 percent. (source)

This says nothing about how sites were developed in terms of good coding practices. For example, if you took unskilled (for lack of better terms) programmers in each language, these numbers could be reversed and perl could have the most vulnerabilities, with .Net having the least. It all boils down to what the code itself is supposed to do. Has the code been programmed to perform its sole function with tampering/abuse tested before it was put into development?

There are plenty of security cheat sheets, best practice guides, and other write-ups that cover security issues but this becomes a situation where the client is weary based on the advice from their provider. This is can be a hurdle since it becomes a "he said" she said sort of struggle to convince your client to allow you to create the site using PHP. A method I might use if I still wanted to use PHP would be to create a demo site, then use a vulnerability assessment scanner (Acunetix, AppScan, Burpsuite) against it to check for flaws. If none are found I would present the report detailing the security posture of what you have built to both the client, and create in such a fashion (PDF, etc) that it is presentable to the provider.

  • 22
    .Net's not a programming language.... Is the article reputable? Commented Jun 28, 2016 at 19:51
  • 7
    @BalinKingOfMoria, when someone says ".Net" in the context of programming languages, they're usually referring to C# with the .Net/CLR runtime. Occasionally they're referring to Visual Basic.NET with the .Net/CLR runtime.
    – Mark
    Commented Jun 28, 2016 at 20:48
  • 12
    So looking at the report you referenced, it says 11% of the sites were PHP but that 15% of the vulnerabilities that were found. That's an over-representation of 36% more than what you would expect if you assume vulnerabilities should be equally distributed across languages. Java and .NET are also over-represented in the vulnerabilities but only by 12% and 11% respectively. By that metric, PHP has (by far) the worst stats in that report.
    – JimmyJames
    Commented Jun 29, 2016 at 16:24
  • 18
    To me this answer is like saying that all cars are equally safe, it's just that the knucklehead drivers are the problem! I think it's inherently inaccurate to talk about a language without talking about the ease of making hard to find errors in that language. PHP is weakly typed, and this leads to making mistakes you'd never make in another language. In essence, the language ALLOWS you to make these mistakes. Putting all the onus on the developer to write perfect code is a mistake, and saying it's purely a coding problem misses the point. Coder and language are not so easily separated. Commented Jun 29, 2016 at 21:40
  • 8
    It's interesting to note that PHP sites "do not have a tendency to be as large or complex as .NET or Java sites but still suffer from many of the same issues". So basically despite being noticeably simpler and less complex, PHP sites had just as many vulnerabilities as the more complex .NET or Java sites. That's like noting that a one million LOC application had similar absolute numbers of bugs as a 100k LOC application and then concluding that both are of similar quality.
    – Voo
    Commented Jun 29, 2016 at 22:02

One of the fundamental problems with PHP is really a fundamental problem with the CGI model of things (upon which PHP is based, despite mod_php's trappings) - namely that user-facing data is intermingled with scripts, and it becomes very easy for e.g. user uploads to become an executable script. This isn't necessarily a problem with PHP itself but having PHP available on a system at all makes it a very large attack surface; quite a few WordPress plugins' security issues come from this aspect of it, for example.

Traditional CGI-based deployments historically mitigated this issue by only allowing CGI scripts to run from a trusted directory (such as /cgi-bin/) but many shared-hosting providers eventually relaxed this restriction for "convenience," and that same convenience is pervasive throughout PHP.

Many modern PHP-based applications often use .htaccess as a quick-and-dirty request-routing mechanism which does help to mitigate these problems, but this is far from universal and still isn't an easy cure.

In my opinion, the biggest problem with PHP is just that it's so easy for arbitrary PHP code to be made available to execute on any server where it's configured, and thus while code written in PHP isn't necessarily more or less secure than code written in other languages (although its standard library doesn't exactly do any favors when it comes to writing secure code), the mechanism by which PHP scripts execute provides a massive security challenge by merit of PHP even being available on a server.


I agree with your assessment that using PHP does not necessitate a security risk. There are some vendors that shy away from PHP for much the same reason that WordPress is viewed as a security risk. It's popular. The more prevalent something is, the more energy gets invested into developing exploits.

That said, I wouldn't avoid PHP if it's implemented properly, receives timely patches, and has some level of monitoring to detect malicious activity. Bottom line: security risks are security risks agnostic of the platform. Changing scripting languages does not mitigate the security risks associated with poorly written / developed / implemented code.

  • 14
    Wordpress is a security risk. Even the core has horrible coding practices and a long history of vulnerabilities.
    – Jacco
    Commented Jun 28, 2016 at 19:38
  • 2
    @Jacco True, but there is bad code in the bowels of lots of applications. WordPress is primarily targeted because it's popular. The core has undergone some improvements in the last few iterations, though still far from perfect.
    – HashHazard
    Commented Jun 28, 2016 at 19:42
  • Name a popular application/system that doesn't have a long history of vulnerabilities. oh yeah android Commented Jul 2, 2016 at 18:42
  • 1
    @ClaudiuCreanga Really? android is the example you're going to use as a system without a long history of vulnerabilities?
    – fluffy
    Commented Jul 4, 2016 at 19:40

If all you want is to include a standard header/footer, PHP might be overkill - simple server-side includes could do that.

PHP is not inherently dangerous, as previous answers have argued. But if you don't need a full scripting language on the server, then best security practice is not to install one. If as you say PHP is going to be installed on the server anyway, then the additional risk created by using it is about zero as long as you don't do anything stupid. And including a template is not stupid unless you somehow parse the file name from an URL parameter.

The contact form will need some kind of API and database behind it to handle the POST request when someone submits it and it's how well this part is written that's going to make or break things - whatever language you use, if it's a SQL database then SQL injection is worth looking out for; if the user's input is in any way echoed back to them or to the client in a webpage then (java)script injection needs to be considered and everything properly HTML-escaped. Compared to the contact form, using an include is as safe as it gets.

If you only wanted a set of webpages, not an interactive web application, the ultimate in security is to use a static site generator - the server only has to serve files which gives a much smaller attack surface.


How much truth is there to the claim that using any PHP script, no matter how simple, is an inherent security problem?

Worded that way, almost none. An include-header script is certainly not a vulnerability. Having PHP installed in the first place when you don't need it is not best security practice, having it installed and not updating it regularly whenever security patches come out is a potential problem, as is not having a policy of who's responsible for these updates - after you've finished the site design will the client be in charge of this? Or the hosting provider? If the client is worried about that, they shouldn't have PHP on the server in the first place. If not, then there's no security-related reason not to use it in places where you know what you're doing.

  • "Having PHP installed in the first place when you don't need it is not best security practice, having it installed and not updating it regularly whenever security patches come out is a potential problem"... Was afraid of that! Unfortunately it's shared hosting, so not much of a choice in that matter. :/ I have to learn more about server side includes, thanks for the tip!
    – Yumecosmos
    Commented Jun 28, 2016 at 17:57
  • 6
    @Yumecosmos If it's shared hosting, the other tenants of the hosting service are a far greater risk than PHP itself. Shared hosts are generally reluctant to install something for just one of the many (sometimes thousands) tenants and will come up with all sorts of reasons to avoid it. A simple "you're on shared hosting, what you see is what you get" would be more honest (and entirely fair).
    – ceejayoz
    Commented Jun 28, 2016 at 18:27
  • 2
    @ceejayoz To that point, almost every time my site has been hacked it's been through another site on the same shared hosting as a vector. There are definitely things you can do to limit that possibility, though, like being very careful about your file permissions and so on. I have a nightly cron job that verifies my file permissions and detects md5sum changes on all my files and a few other things.
    – fluffy
    Commented Jun 30, 2016 at 18:08

Languages and tools aren't inherently insecure, bad code and security practices are.

Since php has a low barrier to entry, people that don't understand network security and secure coding can create security issues with uninformed decisions.

It's not the tool, it's the monkey using it ;-)

Code written in any language can be insecure.

  • 9
    Languages may not be inherently insecure, but they can have proper security principles deeply ingrained in their design. PHP doesn't, and that's an understatement. See eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design
    – Wildcard
    Commented Jun 30, 2016 at 5:01
  • 2
    And that's why everyone should go learn Python! Sorry citing "this other language sucks so learn Python!" sites is bad form. You can write garbage in Python too. I've fixed tons of it. Python isn't a magic bullet for incompetent programmers. You write code using the language your employer has standardized on, or in my case, what the client wants. I'm agnostic myself. I code in Python, php, Java, .net, Perl, and even maintain some old cold fusion sites. Please don't hijack posts to push the Python agenda.
    – Neil Davis
    Commented Jun 30, 2016 at 12:05
  • 6
    I didn't mention Python anywhere. I haven't even learned Python yet (though I'm about to). How in the name of common sense you can interpret my previous comment as "pushing the Python agenda" is baffling. But your answer here basically adds up to "No language is any more secure than any other language," which is nonsense. (This answer provides some specifics as to why.)
    – Wildcard
    Commented Jun 30, 2016 at 17:59
  • 2
    You provided a link to a rabid Python evangelists opinion
    – Neil Davis
    Commented Jun 30, 2016 at 18:05
  • 3
    @user356540 The very first thing eevee says about Python: "I loooove Python. I will also happily talk your ear off complaining about it, if you really want me to. I don’t claim it’s perfect; I’ve just weighed its benefits against its problems and concluded it’s the best fit for things I want to do." That is not the same thing as being a rabid Python evangelist.
    – fluffy
    Commented Jun 30, 2016 at 18:10

"They are reluctant because they were advised by their hosting company that using PHP is a security concern which might allow someone to break into cPanel and gain control of the site"

If the hosting company think they need cPanel to run PHP then its time to move host

You must log in to answer this question.

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