配置文件和密钥管理：别把密码写进代码里

星图导航配图

前几天有个站长加我，说他站被人挂马了，查了两天才找到原因。他把数据库账号密码写在了一个叫 config.php 的文件里，这个文件又放在 uploads 目录下，别人直接输入网址就能把整个文件下载下来。这种事一年能碰上好几回，根子都是一个：密码和代码混在一起了。

密码写进代码，是怎么一步步把站搭进去的

第一个坑是文件位置。你把配置写成 php 文件放在网站根目录，只要服务器上 PHP 解析出问题，或者路径被猜中，源码就可能被当纯文本吐出去。当年不少站就是这么泄的，一次泄露，数据库全裸。

第二个坑是版本库。代码一提交上去，密码就永远留在 git 历史里了。你后面把密码删了、改了，旧的提交记录还在，谁把仓库克隆走，翻一下 log 就能看到当年的库密码。

第三个坑是分享。你把项目打包发给朋友、发给外包、传到某个网盘备份，配置文件跟着一起走。很多人根本不知道自己的压缩包里带着生产环境的连接串。

三个坑叠在一起，泄露几乎是必然的。而且最麻烦的是你不知道什么时候泄的，等发现数据库被人拖走，已经晚了。

正确的做法是把配置和代码彻底分开，代码里只留一个读取入口。比如你写一个 load_config 函数，它负责去固定的目录读一个 json 或者 ini，代码里其他地方再也不出现任何账号密码。

配置文件本身要放在网站根目录之外。假设你的站点在 wwwroot 下面，配置就放到上一级或者专门的 etc 目录，并且目录权限设成 700，只有运行 PHP 的那个用户能读。

文件格式推荐 json 或者 ini，比 php 安全。php 文件最危险的地方在于万一被当源码输出，里面的变量值会原样打印。json 至少不会执行，泄露了也只是数据，不会连带触发逻辑。

还有一个细节，配置文件里不要只放一个数据库密码。把敏感的都集中进去，包括第三方的 api key、短信密钥、支付商户号、邮箱密码，一处管理比到处散着强得多。

环境变量在云服务器和容器里很常见，好处是不落盘、不进仓库，进程启动时注入，代码里用 getenv 取。缺点是调试麻烦，出了问题你看不见它到底注入了什么。

配置文件的好处是直观，出问题打开文件就能看，改起来也方便。缺点是它就是一个磁盘文件，权限配错就可能被读。

我的建议是：数据库这类需要多人协作、经常变的，用配置文件；密钥类、只需要程序自己知道的，用环境变量。两者混用没问题，不必强行统一。

如果你用的是宝塔这类面板，注意它自带的计划任务和守护进程可能不继承你手动设置的环境变量，这类场景老老实实用配置文件更稳。

第一条，绝对不能放在网站能访问的目录里。判断方法很简单：拿浏览器直接敲那个路径，能打开就是放错了。

第二条，权限要收紧。chmod 600 或者 640，属主给 www 用户，不要给 777。777 意味着服务器上任何一个被入侵的脚本都能读写它。

第三条，目录名不要用默认的。很多人把配置放 config 目录，攻击者扫站的字典里第一个就是这个词。换个不起眼的名字，成本几乎为零，收益不小。

第四条，如果服务器上有多个站，每个站用独立的配置文件，别共用一份。一个站被拿下，不至于连带其他站一起完蛋。

第一，写 .gitignore，把配置文件、日志、备份包、上传目录全部排掉。这一步要在第一次提交之前做，事后补会很麻烦。

第二，提交前跑一次敏感信息扫描。不用装什么复杂工具，一个 grep 就够，搜 password、secret、token、key 这几个词，看有没有硬编码的值。

第三，如果你的仓库已经提交过密码，别以为删文件就完事。要用 git filter-repo 这类工具把历史记录一起清掉，然后强制推送到远端，并且立刻把那些密码全部换掉。历史清不干净，等于没清。

顺序很重要，先断后治。第一步立刻改掉所有泄露的凭证，数据库密码、接口密钥、后台账号，一个不留。第二步查日志，看泄露的时间段里有没有异常登录、异常查询、异常导出。

第三步评估影响面。如果泄露的是数据库密码，要假设数据已经被拖走，检查有没有异常的大批量查询记录，有没有陌生的 IP 连进来。

第四步才是修漏洞。很多人反过来做，先把代码改好再改密码，中间这段时间等于门户大开。

还有一点，如果泄露的是支付或者短信这类会产生费用的密钥，改密码的同时要去后台看账单，确认没有被刷。

我的做法是建一个固定的目录，所有站点的配置都集中放，文件名带站点标识，权限统一 600。新建站点的时候复制一份模板，改几个值就行，不会漏项。

然后在本机存一份加密的密码库，用密码管理器，别用记事本。服务器上不存明文备份，需要的时候现查。

最后养成一个习惯：每次改配置，先想一句“这个文件如果被别人下载走，会怎么样”。想不出后果的，说明它本来就不该放在那个位置。