我正在为过去被黑客入侵后担心安全性的客户进行重新设计。我最初建议使用简单的 PHP 包含页眉和页脚模板以及他们想要的联系表单。他们不愿意，因为他们的托管公司建议他们使用 PHP 是一个安全问题，这可能会让某人闯入 cPanel 并获得对该站点的控制权。
对我来说，这听起来像是告诉某人永远不要开车，这样他们就不会发生车祸。我的直觉是，主机试图将责任推给客户，因为他们自己的系统存在安全漏洞。此外，服务器仍然安装了 PHP，无论我们是否使用它，所以我质疑这实际上减少了多少攻击面......但由于我不是安全专家，我不想坚持我的脚在我嘴里。
我告诉我的客户，要处理联系表格，他们将需要某种形式的动态脚本。（假的？）他们问我是否可以在那一页上使用 PHP。这会更安全，还是相当于锁上车门并让车窗摇下？
声称使用任何PHP 脚本，无论多么简单，都是一个固有的安全问题，这有多少道理？我们在没有 SSL 的共享主机上。假设我们因使用 PHP 而被黑客入侵是否合理？如果我们不使用它但无法卸载它，我们会不会更安全？因为如果没有，我们还有其他问题。
（对于任何其他语言，答案会有所不同吗？）
与其说 PHP 本身存在安全问题（假设需要安全更新），不如说是存在许多流行的基于 PHP 的软件，它们存在严重的安全问题。你可能会责怪 PHP 是一种语言，它给你足够的绳索让你窒息，但真正的问题是易受攻击的 PHP 代码实际上是多么普遍。只需查看Stack Overflow PHP 标签即可找到 PHP 新手根据旧教程的一些暴行编写极其易受攻击的代码。
此外，大量以其猖獗的安全漏洞而闻名的流行 PHP 软件基于非常古老的代码和编码实践。由于固有的安全问题，许多这些旧做法被认为是不好的做法。
对我来说，这听起来像是告诉某人永远不要开车，这样他们就不会发生车祸。
几乎是的。更好的建议可能是“不要驾驶没有安全气囊的旧车”。
我的直觉是，主机试图将责任推给客户，因为他们自己的系统存在安全漏洞。
不必要。如果用户对 WordPress 站点和 cPanel 使用相同的密码，则泄露 WordPress 密码也会危及 cPanel。那将是用户的错。不过，黑客很少需要走那么远，只需使用 PHP shell。
我告诉我的客户，要处理联系表格，他们将需要某种形式的动态脚本。（错误的？）
不一定是真的。您可以使用 3rd 方服务来处理邮件发送。然后服务处理动态服务器脚本并接管安全隐患。有许多具有不同功能集的此类服务，它们在为静态生成的站点上的联系表单提供支持方面很受欢迎。
声称使用任何 PHP 脚本，无论多么简单，都是一个固有的安全问题，这有多少道理？
一些，但不多。PHP 确实在 PHP 和执行它的服务器软件中涉及一些活动代码。如果该进程中存在不依赖于特定 PHP 代码的安全漏洞，则可能会被利用。虽然这种风险很小，但没有这种支持的服务器没有这种风险。
“正确”可能不是正确的词，但会想到“明智”、“谨慎”和“认真”。PHP 从一开始就坚持贬低软件正确性的理念。程序可能会遇到大量情况，其他语言（例如 Python）会放弃并抛出错误以告诉您您的程序错误，但 PHP 反而选择做一些无意义的事情并继续进行，就好像事情只是美好的。
请记住，正确性对安全性非常重要。一种倾向于默默地忽略左右错误的语言将有超过其公平份额的存在安全问题的程序。例如，您可能有一段代码，您的程序员认为它可以防止某种攻击，但实际上由于解释器忽略了错误而被跳过。
此外：
real_escape_string因为原始escape_string版本已损坏，但他们直到后来才将其删除）vs . addslashesvs. mysql_escape_string/pg_escape_string等等。而几乎所有其他语言都只是使用准备好的语句和查询参数，并且在第一次尝试时就获得了可扩展到所有数据库的设计。因此，对于其他答案中关于如何在 PHP中编写安全软件的所有讨论，如果您尝试它，那么您将非常反对当前。
PHP的安全问题一般可以归结为两类
截至目前，Wordpress 统计数据显示，超过一半的用户正在使用已过生命周期终止的PHP 版本（PHP 5.2 - 5.4）运行 PHP。在两周内，PHP 5.5 进入 EOL，然后跃升至所有安装量的 80% 左右。现在，公平地说，一些 Enterprise/LTS Linux 安装将向后移植安全修复程序，但其中绝大多数没有使用向后移植的修复程序（或者有些不修补他们的系统）。更糟糕的是，很多人拒绝升级 PHP 本身。他们要么不能/不会更新他们的代码，要么他们认为旧软件更稳定。
Wordpress（全球使用的#1 PHP 应用程序）齐心协力确保用户及时了解软件本身（并且他们取得了长足的进步），但尽管如此，只有 40% 的用户在运行最新版本的 Wordpress。这意味着大约 60% 可能存在未修补的安全漏洞。这只是基本程序。Wordpress 拥有庞大的插件生态系统，其中许多都有自己的安全漏洞。
然后还有其他问题，例如许多使用已失效mcrypt 库的旧代码。这只是您可以编译的一个 PHP 插件。
现在将此推断到未运行并向 WP 报告统计信息的服务器。它没有描绘出漂亮的画面。去年夏天，我发现一个运行电子商务页面的网站仍然使用 Apache 1.3.3 和 PHP 4.1.2。它太旧了，它启用了 SSLv2 ......
如果你在 SO PHP 问题上停留的时间足够长，你会看到很多人在练习糟糕的代码。这些年来我看到的一些问题
ext/mysql旧的 MySQL 连接器）对于未经训练的人来说，这看起来像是一个 PHP 问题，因为是程序员和他们的生态系统产生了问题。也许他们很着急。也许他们聘请了一些在业余时间做这件事的人，并且“让它发挥了作用”。
是的！但这种安全性需要付出一些努力。使您的 PHP 安装保持最新。哎呀，让你的整个服务器保持最新状态。主机不会做安全和补丁？寻找另一个主机。（我对那些对此犹豫不决的人感到惊讶）。构建自己的服务器（虚拟机很便宜）。但最重要的是，请注意。尽可能了解安全性。不要只是让您的网站和服务器出海。
告诉你 PHP 不安全的人只是懒惰。
PHP 不比任何其他语言（Java、Rails 等）更安全、更安全或不安全。这都是关于编码的。是否有适当的制衡机制来转移、防御、预防和/或减轻攻击。报价：
WhiteHat Security 使用 .NET、Java、ASP、PHP、Cold Fusion 和 Perl 对 30,000 多个网站进行了漏洞评估。使用最广泛的语言是 .NET（占 Web 应用程序的 28.1%）、Java（24.9%）和 ASP（15.9%）。
...
编程语言 .Net 每个插槽平均有 11.36 个漏洞，Java 11.32 和 ASP 10.98。最安全的语言 ColdFusion 每个插槽有六个漏洞。Perl 每个插槽有 7 个漏洞，而 PHP 有 10 个。
...
Java 占发现漏洞的 28%，ASP 占 15%。报告称：“再次，必须将使用该语言编写的应用程序数量以及网站的复杂性视为一个促成因素。” PHP 还占已发现漏洞的 15%。ColdFusion 仅占漏洞的 4%，Perl 占 2%。（来源）
这并没有说明网站是如何根据良好的编码实践开发的。例如，如果您选择每种语言的非熟练（由于缺乏更好的术语）程序员，这些数字可能会颠倒过来，perl 的漏洞可能最多，而 .Net 的漏洞最少。这一切都归结为代码本身应该做什么。在投入开发之前，代码是否已被编程为执行其唯一功能并经过篡改/滥用测试？
有很多安全备忘单、最佳实践指南和其他涵盖安全问题的文章，但这会导致客户根据其提供商的建议感到厌倦。这可能是一个障碍，因为它变成了“他说”，她说很难说服您的客户允许您使用 PHP 创建网站。如果我仍然想使用 PHP，我可能会使用的一种方法是创建一个演示站点，然后对它使用漏洞评估扫描程序（Acunetix、AppScan、Burpsuite）来检查漏洞。如果没有找到，我将向客户提供详细说明您为客户构建的安全状况的报告，并以可呈现给提供商的方式（PDF 等）创建。