Php 直接脚本访问时终止

我在一些php项目中克服了这种安全措施。在每个php文件的顶部，都会检查脚本是否通过直接访问（例如通过浏览器）调用，或者站点入口点是否正确包含/要求脚本：

if(!defined('SYSTEM_ENTRYPOINT'))
    die();

---

这是在php项目中使用的良好实践吗？这样做时我应该考虑什么？有边缘案例吗？不检查此项时可能会暴露哪些数据？

您应该通过URL重写来处理此问题。组织php文件的方式使访问者无法接触您的程序逻辑

例如，将代码分为两个目录：web和src。Web页面只包含index.php和htaccess文件，用于将所有请求路由到该文件。Src应包含所有程序逻辑（控制器、db访问abd等）。在src/index.php内部，编写一些逻辑代码，这些逻辑将决定要包括src文件夹中的哪个控制器

---

将“web”目录设置为站点的web根目录，访问者将无法访问任何其他php文件。

如果您的所有php文件都在webroot之外，并且您只在webroot中公开入口点，我相信您将不需要该目录。@frz3993在我目前的情况下，所有内容都在一个位置。确定。然后，这取决于你的文件中有什么。假设一个文件只包含变量或类。直接调用它只会生成一个空白页。如果文件中有一些指令，它们肯定会被执行。这要视情况而定，但99%的文件只包含类。您是否认为检查此项仅在具有“直接代码”的文件中才有意义？我担心php错误消息中的信息可能会帮助可能的攻击者窥探或获取有关项目结构的其他信息。我认为是的，只有使用“直接代码”才有意义。是的，错误消息可以告诉你很多关于结构的信息，例如，如果你的入口点没有包含一个文件，错误消息将显示该文件的路径，即使你进行了检查。如果直接导航到类文件，则不会显示错误，因为它不处理任何内容。在生产环境中，我通常会重定向到错误页面并记录或邮寄错误。永远不要让错误显露出来。这将是一个解决方案，我之前也考虑过这一点。我使用常量来定义源代码的几个重要位置，所以这并不是什么大事。我现在就接受这个答案，但也许对最初的想法还有一些贡献。如果可能的话，将vhost（Apache，nginx）配置为指向

public/

目录，并将所有应用程序代码，尤其是配置文件保留在此目录之外。i、 e.

/var/www/public

和

/var/www/src

。