"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.

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.

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.

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.

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.

So:

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.

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.

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.

PHP by itself has not much more vulnerabilities than any other language. The problem with PHP is that it allows spaghetti code, where view, business rules and database access are all mixed in the same file: no separation on concerns, rapid developpement and hard to maintain code is the plague of some low experienced developpers.

In contrast, a Java-EE application build on top of an ORM like Hibernate, a MVC framework like Struts or Spring-MVC helps (forces?) the developper to build a layered application, where each layer can be tested independently. The initial developpement requires more time, more technicity from the developpers but a simple application of the best practice rules should lead to a clean and neat maintainable code. I agree, it is easy to write a poor application in Java... but the dev is really to blame in that case!

Another reason why admins are reluctant to use PHP for serious apps, is that there is a lot of code around for PHP of variable quality. Zend has a good reputation, not all PHP libraries and examples are. In contrast major java libraries are used in highly sensitive applications and for that reason have been thoroughly tested for possible flaws for years.

TL/DR: It is possible to write a clean and secure application in PHP but it requires a volontary action from the developper team, because it is so easy to simply script the application. In contrast, a Java-EE - Spring-MVC - Hibernate application natively requires a layered design.