网站源码泄露是服务器配置不当引发的最严重安全问题之一。攻击者一旦获取你的PHP、Python或Node.js源代码，数据库密码、API密钥、业务逻辑、加密算法全都暴露无遗。很多开发者以为只要网页能正常显示，源码就安全了，但实际情况是，一个简单的文件包含漏洞或目录遍历漏洞，配合宽松的文件权限设置，就能让攻击者像浏览自己硬盘一样翻阅你的整个项目目录。
根本原因在于Web服务器进程需要对文件拥有“读取”权限才能执行脚本，但如果权限设置过宽，比如设为777或644，那么同一服务器上的其他用户、甚至通过漏洞进入系统的恶意进程，都能直接读取这些文件的内容。更危险的是，配置文件、日志文件、版本控制目录如果权限失控，等于把数据库凭证和系统路径拱手送人。
解决这个问题的核心思路是：让Web服务器进程能执行代码，但禁止非授权用户直接读取源码文件。这听起来矛盾，实际上通过精确的用户组划分和权限位设置完全可以实现。下面从Linux服务器环境出发，给出具体的操作方案和验证方法。
理解Web服务的用户与组Nginx或Apache启动后，会以一个特定系统用户的身份运行，通常是www-data、nginx或apache。PHP-FPM同样以某个用户运行，这个用户必须对项目文件拥有读取权限。关键点在于，你的项目文件所有者应该是你自己的SSH用户，而不是Web服务用户。通过将Web服务用户加入一个专门的用户组，并给这个组分配最小的必要权限，就能在“可执行”和“不可随意读取”之间取得平衡。
假设你的项目部署在/var/www/myapp目录下，你通过SSH登录的用户是deploy，Web服务运行用户是www-data。正确的做法是：文件所有者为deploy，所属组为www-data，权限设置为750（目录）和640（文件）。这样deploy可以读写，www-data组可以读取，其他用户完全没有任何权限。
目录权限设置为750目录的权限直接影响能否进入该目录并列出其内容。750意味着所有者拥有读、写、执行权限（7），所属组拥有读和执行权限（5），其他用户没有任何权限（0）。执行权限对于目录来说不是运行程序，而是允许进入该目录。Web服务用户需要进入目录才能访问其中的文件，所以必须给组加上执行位。
设置命令如下：
find /var/www/myapp -type d -exec chmod 750 {} \;
这条命令递归找到所有目录，统一设置为750。注意目录必须有执行位，否则Web服务器连index.php都无法定位。
文件权限设置为640普通源码文件不需要执行位，640即可满足需求：所有者可读写，所属组只读，其他用户无权限。PHP、Python、HTML、CSS、JavaScript等文件都适用这个规则。设置命令：
find /var/www/myapp -type f -exec chmod 640 {} \;
这里有一个容易被忽略的细节：如果某些文件确实需要可执行权限，比如Shell脚本或编译好的二进制文件，可以单独设置为750。但绝大多数Web项目的源码文件都不需要执行位，设置执行位反而增加风险。
配置文件权限收紧到600或400包含敏感信息的配置文件，比如.env、config.php、database.yml，应该设置为600，即只有文件所有者可以读写。Web服务用户通过PHP-FPM运行时，PHP-FPM主进程以root启动，但工作进程会切换到配置文件中指定的用户。如果你让PHP-FPM工作进程以deploy用户运行，那么600权限的文件就能被读取。如果PHP-FPM以www-data运行，则配置文件需要640，但这样安全性稍差。更推荐的做法是让PHP-FPM池配置中的user和group与项目文件所有者一致，这样配置文件就可以收紧到600。
chmod 600 /var/www/myapp/.env chmod 600 /var/www/myapp/config/production.php
对于极端敏感的文件，甚至可以用400权限，连所有者都不允许写入，防止应用层漏洞导致配置文件被篡改。
上传目录的特殊处理用户上传的图片、附件等存储在类似uploads或storage的目录中。这些目录需要Web服务用户能够写入，因此权限设置与源码目录不同。通常设为770（目录）和660（文件），所有者为deploy，所属组为www-data。这样Web服务进程可以写入，但其他用户仍然无法访问。
chmod -R 770 /var/www/myapp/storage chmod -R 770 /var/www/myapp/public/uploads
务必确认上传目录不在源码目录的同一层级，最好放在项目根目录之外，或者至少确保上传目录内不能执行PHP脚本。Nginx可以通过location规则禁止特定目录的脚本执行。
禁止PHP执行上传目录中的文件即使上传目录权限设置正确，攻击者如果上传了一个PHP文件并通过某种方式访问它，仍然会造成代码执行。在Nginx配置中增加以下规则，直接返回403或强制下载：
location /uploads/ {
location ~ \.php$ {
deny all;
}
}
Apache用户可以在.htaccess中添加：
<FilesMatch "\.php$">
Deny from all
</FilesMatch>
这样即使有人上传了Webshell，也无法通过HTTP请求触发执行。
Git目录和版本控制文件必须屏蔽.git目录如果暴露在Web可访问路径下，攻击者可以直接下载整个仓库的历史记录和所有源码。无论权限怎么设置，最安全的做法是在Web服务器层面直接禁止访问这些隐藏目录。Nginx规则：
location ~ /\.git {
deny all;
return 404;
}
location ~ /\.svn {
deny all;
return 404;
}
同时，部署流程中应该排除.git目录，不要让它出现在生产环境的Web根目录下。现代CI/CD工具都可以在打包阶段自动忽略这些版本控制文件。
PHP-FPM用户隔离如果一台服务器上运行多个网站，每个网站应该使用独立的PHP-FPM池，并且每个池以不同的系统用户运行。这样即使某个网站被攻破，攻击者也无法读取其他网站的源码，因为文件权限已经通过640/750将“其他用户”完全隔离在外。PHP-FPM池配置示例：
[site1] user = site1_user group = site1_group listen = /run/php/site1.sock [site2] user = site2_user group = site2_group listen = /run/php/site2.sock
对应的网站目录权限：site1的文件所有者为site1_user，所属组为site1_group；site2的文件所有者为site2_user，所属组为site2_group。两个用户互不相干，即使在同一台物理服务器上也实现了源码级别的隔离。
验证权限设置是否生效设置完成后，必须实际测试。用另一个普通用户SSH登录服务器，尝试读取你的源码文件：
sudo -u nobody cat /var/www/myapp/config/database.php
如果返回“Permission denied”，说明权限生效。再用Web服务用户测试：
sudo -u www-data cat /var/www/myapp/public/index.php
这条命令应该成功输出文件内容，因为www-data在所属组中，拥有读取权限。同时测试www-data能否写入源码文件：
sudo -u www-data touch /var/www/myapp/public/test.txt
应该失败，因为组权限只有读没有写。最后测试能否列出目录内容：
sudo -u nobody ls /var/www/myapp
应该提示权限不足。
常见错误与纠正很多教程推荐使用775或755权限，理由是“方便省事”。但755意味着“其他用户”拥有读和执行权限，服务器上任何一个被攻破的WordPress站点都能遍历你的自定义项目目录。777更是灾难，任何进程都能读写执行。除非你完全清楚自己在做什么，否则永远不要在生产环境使用777。
另一个常见错误是使用chown将文件所有者改为www-data。这样Web服务进程拥有了文件的完全控制权，一旦应用存在任意文件读取漏洞，攻击者就能修改源码植入后门。文件所有者应该是你的部署用户，Web服务用户只通过组权限获得最低限度的读取能力。
还有一种情况是某些框架要求特定目录可写，比如缓存目录、日志目录。这些目录应该单独设置权限，不要为了方便直接把整个项目目录改成777。用chmod -R 777解决问题是安全实践中最坏的习惯。
SELinux和AppArmor的额外保护层如果服务器启用了SELinux或AppArmor，即使传统权限设置正确，这些强制访问控制系统也能提供额外防护。SELinux可以配置策略，规定Web服务进程只能访问特定标签的文件，即使文件权限为777，没有正确标签的进程也无法读取。对于高安全需求的环境，建议投入时间学习并启用这些工具，它们能在内核层面拦截违规的文件访问操作。
定期审计和自动化检查权限设置不是一次性工作。开发人员可能无意中修改了权限，新部署的代码可能带着错误的默认权限上线。编写一个简单的Shell脚本，定期检查关键目录和文件的权限是否符合预期：
#!/bin/bash
find /var/www/myapp -type f -perm /o+r -exec echo "警告：文件权限过于宽松 {}" \;
find /var/www/myapp -type d -perm /o+r -exec echo "警告：目录权限过于宽松 {}" \;
把脚本加入crontab或CI流程，一旦发现异常立即通知运维人员。自动化检查是防止配置漂移的有效手段。
源码泄露的后果往往比想象中更严重。一个配置不当的服务器可能在几分钟内被自动化扫描工具发现并利用。通过严格执行750/640权限模型、隔离上传目录、屏蔽版本控制文件、配合PHP-FPM用户隔离，可以构建起多层防护。这些措施不需要额外安装软件，完全利用Linux原生的权限系统，成本为零，效果立竿见影。关键是养成习惯，在项目初始化阶段就按这个标准配置，而不是等出问题后再补救。
