符号链接（ln）设为可执行时，其指向的非可执行目标文件是否存在暴露风险？

直接给你拆解清楚——这个问题的答案取决于你的Web服务器配置、文件权限以及符号链接的结构，不能一概而论，但核心要点如下：

1. 工具文件被直接访问的可能性 #

• 如果你的tool.php本身就放在Web服务器的可访问根目录（比如Apache的DocumentRoot、Nginx的root目录）里，那不管有没有符号链接，只要外网用户知道这个文件名，就能直接通过http://你的域名/tool.php访问到它——除非你在服务器层面加了访问控制规则（比如.htaccess、Nginx的location限制）。
• 如果tool.php放在Web根目录之外，只要服务器配置没允许访问外部目录，同时PHP的open_basedir也没放开对应路径，那就算有符号链接指向它，外网也没法直接访问到这个文件。

2. 通过index.php -> symlink -> tool.php路径的访问风险 #

你说的这种符号链接链，分两种场景来看：

• 文件系统层面的符号链接链：也就是index.php本身是个符号链接，指向另一个symlink，最终指向tool.php。这种情况下，Web服务器会自动解析整个链接链，用户访问http://你的域名/index.php其实就是在运行tool.php的代码。如果这个工具是需要权限验证的管理类工具，而index.php又没加任何访问控制，那外网用户访问这个路径就等于直接使用你的工具，风险拉满。
• index.php内部调用符号链接：比如你在index.php里用include('symlink')或者require来调用符号链接指向的tool.php。这时候PHP会解析符号链接并执行tool.php的代码，同样的，如果index.php没有身份验证（比如登录校验、IP白名单），外网用户访问index.php就会触发工具的执行，一样有风险。

3. 关键防护建议 #

• 隔离工具文件：把tool.php放到Web根目录之外，只通过PHP内部的include/require来调用，同时设置PHP的open_basedir限制，只允许访问指定的安全目录，防止越权访问。
• 加访问控制：要么在index.php里加身份验证逻辑（比如账号密码登录），要么在Web服务器层面（.htaccess、Nginx配置）加HTTP Basic Auth或者IP白名单，只让可信的用户/IP访问。
• 管控符号链接配置：如果不需要用符号链接，直接关掉Web服务器的跟随符号链接选项（比如Apache的Options -FollowSymLinks）；如果必须用，开启SymLinksIfOwnerMatch，只跟随和Web服务器进程同属主的符号链接，降低权限泄漏风险。
• 简化结构：没必要搞多层符号链接，直接让index.php包含或者指向tool.php就行，结构越简单，潜在风险越少。

内容的提问来源于stack exchange，提问作者Magezilla