Thanks for the answer! +1 cause this is good advice in general. In our case we're not looking at anything as complex as WordPress. Pretty much all the PHP code I'm going to be using amounts to require_once('path/to/header-template.php'); But perhaps the host's comment was in reference to old scripts I haven't seen.

I do have one objection to your first paragraph: if it's an old version of PHP, the language/runtime itself probably do have significant security problems. (Just how old that would have to be, I couldn't say.) Also, the fact that it has such a bad history may be a reason some developers would cite not to trust even its most up to date form. Even if you disagree with that analysis or if other languages actually have a less well known but similar history, I don't think you can simply dismiss the point.

@jpmc26 A fair point that running outdated PHP versions is far too common. Of course, running an obsolete version of anything is just a bad idea. If people run unsupported versions, they've really have nobody to blame but themselves.

Its pure prejudice. C gives you enough rope to choke you, the sheriff and the damn stinky dog. Yet nobody is badmouthing C

@Mindwin Zed Shaw is. lol. I actually think you underestimate the negative perception of C. It's often viewed more as a necessary evil than as a great language, and when it's not, it's viewed as a good high level assembler. Plus, aside from well tested web servers serving static files, web code is generally not written in C, so there's a lot less to criticize. But I think most web developers would agree that C isn't a good choice for web, precisely because it would be so easy to create vulnerabilities.

@Alexander To be fair there is a large difference between the quality of implementation of PHP and other languages. For example the Oracle JRE had 8 high CVE vulnerabilities in 2016 so far, PHP had 42.

@Mindwin People absolutely badmouth C from a security perspective. Not many people have the skill and/or desire to write a website in C, that's the main difference.

@voo vulnerability counting is a terrible metric to compare how secure things are.

@wireghoul: But it's a fairly good way to compare how insecure things are

I would say vulnerability counting is a good metric for risk assessment, but not a great metric for measuring how secure an implementation actually is because usage share also plays a factor into how many vulnerabilities are found.

@Alexander Sure some obscure application will have less published vulnerabilities because less people are looking for it. Java and PHP are both reasonably similar in popularity, so this seems like a fair comparison. Entertaining anecdote to the quality of implementation of PHP (please if anybody has something similar for HotSpot share, I love these things).

@Yumecosmos It is all going back to how smart your userbase is. As I like to call it "human stupidity can't be patched" this isnt my Quote, but I dont know who ownes it so. If you want to reasonably sure regardless of language. Use multiple database users. Don't give any user a single right more than they NEED. Don't force users to reset Passwords to often it makes for easy to hack/guess Passwords. But most of all if I really want to break your security I will, all you can do is make it hard.

@slebetman not at all see plus.google.com/+JustinSchuh/posts/CNEgtJWYTb5 and wickhill.com/blog/main-category/… and blog.osvdb.org/category/vulnerability-statistics for some more information on why this is a fallacy.

@wireghoul I did read the google plus post and the reasons mentioned there can be summarized as: a) nobody is looking for bugs in obscure software (not an issue here, since neither project is obscure and people are looking for bugs), b) software makers might not publish internally found vulnerabilities if they're closed source (not true for either project and they do publish their found vulnerabilities). The second link talks about risk assessment which again is not relevant here (already done by CVE and we only count high risk exploits). The third one doesn't strike me as relevant at all.

I took a course from Troy Hunt once, and he referred to choosing the right platform as "falling into the pit of success."

@Mindwin arguably the C was good for what it was designed for - high-level assembly for writing system code. It is sometimes (ab)used to do much more but it was never designed to program webpages as it predates TCP/IP. Sure you can write a webpage but it's like complaining that hand-saw does not have safety features of modern tools and you can cut yourself. In comparation PHP (last time I've touched it) was more akin to a chainsaw where there is no protection between hand and saw - it is designed (well, evolved) to be used for webpages and it record is... questionable.

RE not necessarily need dynamic scripting to process enrollment form: I don't understand what you're trying to say there. That instead of writing your own enrollment form page, you could use an enrollment form on some other server? I suppose so, if they implemented exactly what you need, but that's a huge IF. And in any case there still is some sort of scripting, now it's just a program written by someone else instead of you. Whether it's more or less secure depends on the relative skill of them and you, etc.

@Jay There are several such services with varying feature sets. Here's one for contact forms: formspree.io Basically the advantage is you offload the scripting and security implications to a 3rd party server. It wouldn't be something you would run on your own server, and potentially allow your server to have no such scripting support.

@JimmyJames learnbchs.org/index.html

"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." This is the answer, though, it would be nice if you mentioned if such an exploit was known to currently exist in the most recent release of PHP. That is what would determine if PHP is inherently insecure or not. Furthermore, it would require that the programmer use the facilities that presented this vulnerability in his own code.

@Mindwin Uh... nobody bad-mouthing C for its vulnerabilities? Which rock have you been hiding under? As an ex (and I mean very ex) C programmer I've heard the language abused for its contribution to security flaws for decades. C and its buffer overflow bug collection is probably the main reason why so few languages support - and so few programmers understand - pointer arithmetic these days.

@BonAmi I'm not sure what this response means. I never claimed no one is doing this. I claimed that not many people are inclined to do it (relative to the number of people using PHP.) I see no evidence here to the contrary.

Great answer. Love the airbags analogy.

If we want to compare PHP to Java, we have to remember to since PHP is scripted and dynamically typed, it's easier to add security breaches. However, SQL injection and so on are still valid whatever the language you choose. Java just bring things out of the box that help a lot against some others vulnarabilities of languages, if we want to compare to C, in Java you can't generate write instruction in a memory by exploting some buffer overflow. Finally there is a looot of developers that just to make it works, security ? A loss of time and energy. "It won't happen to me" syndrom.