根据我的定义，一种语言很难“天生不安全”，因为优秀的程序员可以适应。但是 PHP 一开始就给新手留下了很多雷区。

PHP 的初始版本很少关注安全性，并且设计存在一些大缺陷。安全性很难改造到核心软件和库中。在最好的情况下，安全培训是很困难的，当大部分开发人员缺乏经验并且从糟糕的默认设置开始时更是如此。

例如，直到 4.2.0 版本才默认禁用 register_globals，因此通过网络接收的数据不再直接插入到全局命名空间中。此功能最终计划在下一个版本中完全删除。

PHP 的早期发布和简单的 PHP 应用程序的易于部署也吸引了许多安全意识不强的开发人员，并确保了大量的应用程序，其中相当一部分存在可远程利用的漏洞。部署基地的规模和脆弱性也引起了漏洞利用社区的极大兴趣。

以下是一些参考资料和有用的链接

• PHP 不安全 - 技术评论
• PHP 的安全性如何？- 堆栈溢出
• 关于“本质上不安全”的参考资料：http ://www.sitepoint.com/forums/showthread.php?threadid=112694
• PHP 安全联盟
• http://en.wikipedia.org/wiki/PHP#Security

这至少有两点：

1. PHP 非常普遍，这使它成为黑客的有趣目标。这也意味着很多新手程序员使用 PHP，因为它易于使用。因此，如果您在应用程序中包含第三方库，您更有可能选择不安全的代码。

2. 而且我想更重要的一点是 PHP 的设计并不是为了像今天这样大规模使用。Rasmus Lerdorf 编写 PHP 来替换他使用的一些 Perl 脚本，并从那里发展而来。因此，当他编写它时，安全性并不是最重要的方面，而且他决定使用回来的很多东西（因为它更容易编程）现在都是安全风险。

更受欢迎的主题是 - 它引起的更多关注。这是第一个真理。第二个事实是 PHP 从一开始就设计得不是很好，现在它有很多内部黑客才能正常工作，这一直导致安全实现失败，版本不兼容。作为最好的证明，您可以检查MOPS。我真的不认为有更多的讨论。

主要问题是默认配置和低门槛。

部署 PHP 应用程序的最简单方法是安装名为“Apache”的低效恐怖应用程序mod_php，将开发不佳的应用程序投入/var/www其中，然后看着世界燃烧。这会奏效，但这是一场安全灾难。

例如，Node.js 应用程序作为自己的进程运行，在其自己的目录中完全独立于 Web 根目录。Web 根目录仅用于存储资产和用户上传的内容，如果应用不需要（例如，如果它只是一个 REST API），则可以将其省略。如果 .js 文件被上传到那里，不会发生任何不好的事情（它可能会造成客户端损坏，例如网络钓鱼或 XSS，但这超出了范围）。

另一方面，使用我们的默认 PHP 配置，如果 .php 文件被上传和请求，它会在合法应用程序的权限下执行，可以访问和修改其文件，访问和从数据库中窃取敏感数据等。这是一场灾难，PHP 网站的大多数妥协都来自不安全的文件上传表单。

有一些方法可以确保安全，例如将应用程序和内容分开 - 应用程序的文件不应通过 Web 根目录访问，并且不应从内容目录执行任何文件。大多数框架都使用这种方法，所有控制器、模型和视图都驻留在app目录中，第二个public目录包含所有资产、上传的内容和一个index.php文件，该文件是应用程序的入口点，用于引导框架和应用程序。然后，您将 Web 服务器配置为将该public目录用作 Web 根目录，并且仅index.php在将其他所有内容作为内容提供时执行。即使.php上传了恶意文件，它也只会以纯文本的形式提供，让全世界在白痴企图入侵网站的情况下伤害他们的眼睛。

那么为什么不是每个人都这样做呢？因为“嗨，我如何在 cpanel 免费托管上安装 laravel 框架？谢谢”

因为这样的人。真正的低门槛意味着相当多的 PHP 用户不是开发人员，也不想成为开发人员 - 请注意，我不认为他们是开发人员，因为在不理解的情况下复制/粘贴教程中的代码并不意味着成为开发人员，这仅意味着成为一个不负责任的白痴-只有当您能够花时间了解自己在做什么以及如何以正确的方式做事时，您才能成为开发人员。我可能有偏见，但这也意味着在设置面向 Internet 的 Web 服务器之前，请访问 Stack Exchange 并阅读一些有关服务器安全的基本内容。;)

鉴于他们不能使用应用安全指南，也不能在共享主机上使用框架（并且不要费心迁移到虚拟机/专用服务器，因为它需要一些他们不想做的阅读，因为共享主机似乎对他们来说已经足够好了，并且PHP 共享主机通常是免费的）他们继续创建蹩脚和不安全的应用程序，并将它们部署在蹩脚且已经受到攻击的 cPanel 驱动的共享主机服务器上。