No time for an answer, but OWASP PHP Cheat Sheet lists many reasons why PHP is less secure than other languages

CVE's PHP flaws contain dozens of high (CVSS >=7) issues just in the past couple of months. That seems pretty bad to me.

You don't need any scripting at all to have a contact form. Just static HTML will do, since you can recieve the submissions in your email.

cPanel's a bigger risk than PHP itself is.

@Anders It's all fun and games until someone doesn't have an email client installed/configured.

@MonkeyZeus Good point.

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

To me it sounds like "Never drive a Pinto, even if it's just on an empty parking lot."

@NeilSmithline I'd just like to encourage you to write up an answer later comparing those results with other languages. Even though the OP has already accepted an answer, I'm sure a lot of us would appreciate it.

Holy cow. I didn't mean to start a programming language religious war. XD

@NeilSmithline Just for comparison from the site you linked. PHP CVE's level 7 or above: 187. Python's CVE's level 7 or above: 6. Ruby on Rails CVE's level 7 or above: 15. That's 1 or 2 orders of magnitude less.

@Yumecosmos You didn't. You just walked into an existing war zone. The issue of PHP being good or bad has been a battle ground for at least a decade. Probably longer. Some of us that fall on the side of it being bad do try to be reasonable, though. ;)

The main problem in PHP is the bad documentation surrounding it like outdated docs and 10 year old kids doing "tutorials" which include insecure and deprecated code. There are ways to write decent and safe PHP.

If you are a good PHP programmer (who follows the best practices) and the website is simple with few forms, you really have to be careless to make it unsafe. However adding complexity will increase your chances of forgetting something, specially if you are a lone wolf.

If they're using cPanel then they have no friggin' leg to stand on to complain about other code being insecure.

you can use php for just that page, and you can include html files instead of php files. that should be as safe as SSI. the main issue is user input, which it sounds like there is none... You could also load the header and footer with javascript and composite the page client-side

@Yumecosmos commitstrip.com/en/2015/01/12/the-right-tool-for-the-right-job

It is uncontroversial in general that some languages make it harder to write safe code than others.

In order to be insecure, avoid programmers and administrators that do not know what they are doing. It may be true that there are many of those in php-land, but you will be able to find them anywhere. Unfortunately, the hosting company has shown it does not know what it's doing through this claim.

@usr It could be argued, though, that languages in which it is harder to write unsafe code tend to blindside the programmers when there is a way to do it wrong. For example, in C++, any good programmer follows RAII and won't leave file handles lying around, while in a memory managed language, this pattern is often not required, leading to more leaked file handles (because there it is necessary).

@Jasper In C, if you initialise a string with char stringvar[13] = "Hello, World!";, you have a potential security vulnerability. If you have a 256-char long buffer and write more than 256 bytes into it, there goes your code. If your password input buffer size isn't the hard limit of the password length, the password doesn't even need to be entered correctly to gain access, so long as the attacker knows the runtime memory map. It's all relative.

@wizzwizz4 I don't see how that relates to my comment at all. I'm just giving an example of how "making it easier to write good code" can blindside people where it is possible to do thing wrong. It's something to keep in mind, not to pick one or the other language over. I'm not arguing for or against any language. I even took an example that does not use languages that relate to the battle being fought here...

It's perfectly safe to write PHP if you're an expert and know how to avoid all the foot guns in the same way it's perfectly safe to walk in a minefield if you know where to put your feet.

@Jasper I get that point but having to constantly avoid certain traps does not mean you are more vigilant towards other traps. The individual traps seem independent to me. This makes it all about the numbers and probabilites. I don't believe in any general vigilance effect.

@Jasper I was just showing a few counter-examples. (1) A programmer who doesn't know about null would think that a thirteen character long string only needs 13 bytes. (2) Extending that to a buffer, you can accidently overwrite some important data or code. (3) If any user can overwrite that important data or code with other data or code, there goes any hope of security.

@wizzwizz4 Those aren't counter-examples because I never claimed "languages with easy unsafe code" are better, or only have advantages. Instead, I only meant to show there is another side to the "undisputed" claim usr made. I never argued for any type of language over any other.

@usr I don't think that's the way you should look at it. First off, knowing what your system does gives you a better aptitude at finding problems with it. A C++ programmer might realize what is wrong with the file handle, even if he has never encountered it before and if he doesn't, you can explain the problem in a sentence or two. The programmer from a pure managed background will need more time to grasp what the problem is.

Secondly, pitfalls should cause better design (like RAII) and better design should help avoid other pitfalls. It's not about "general vigilance".