「都说安全很重要，可到底该先从哪儿下手？」——这就是写给这样的个人开发者的、最最开始的第一步。不是为了吓唬你，而是只把从今天就能动手的事，按顺序讲清楚。
为什么要从「秘密的值」开始
真实发生的事故，很多都不是什么高级攻击，而是从**「秘密的值泄露了」**开始的。本站拿来作为出发点的两个案例，也都是秘密泄露：
也就是说，只要能守住秘密的值，常见事故里的绝大多数就都能防住。所以我们就从这里开始。
.env 是什么（30 秒讲完）
.env（点 env）是把应用要用的秘密的值汇总到一起的配置文件。里面装着数据库的密码、外部服务的 API key、给会话加密用的密钥等等。正因为钥匙都集中在一个文件里，一旦泄露就会一口气全部泄露，所以要最优先地守好它（→ 术语：.env 是什么）。
API key 泄露后会发生什么
API key 是「以你的身份去使用外部服务的、配出来的一把钥匙」。它一旦落到别人手里，就会这样连锁下去。
被偷走的 key 往往会有时间差地被转卖、滥用，「泄露刚发生时啥也没有→过些天账单突然飙升」是很典型的套路。所以「等发现了再说」就晚了，关键是从一开始就别让它泄露。
从今天就能做的 4 个防护办法
不需要什么难的东西。先做好这 4 件就行。
不公开
别把 .env 和应用本体放到 Web 上能看见的目录（公开根目录）里。对外公开的只能是 public/。在虚拟主机上的具体操作步骤见 这篇文章。
不提交
在 .gitignore 里加上 .env*（!.env.example 可以放行）。只共享不带值的样例。一旦提交过就能从历史里恢复出来，所以从一开始就别放进去。
泄露就全部更换
不是只换一个，而是把有可能泄露的钥匙全部轮换。优先顺序是「外部 API · OAuth → 加密密钥 → 邮件 → DB」。按「已经被看到了」的前提来处理。
自查
偶尔确认一下自己的网站，看 /.env 能不能从外面打开（见下）。
自查（只对自己拥有的域名做）
# 返回 200 且带正文就是被公开了。403/404 则暂时没问题
curl -sI https://你的域名/.env | head -1
curl -sI https://你的域名/.git/config | head -1养成每次上线都确认一遍的习惯，就能尽早发现放置位置的失误。
容易犯的错 vs 正确的第一步
容易犯
- 反正先跑起来了，就把
.env直接放在 public 下 - 想着「以后再删」，把
.env提交进 git 一次 - 只换那一个看到被滥用的钥匙
正确的第一步
- 本体放在公开根目录之外，只公开
public/ - 从一开始就用
.gitignore把.env排除掉 - 泄露了就把 env 里的钥匙全部轮换
下一步
走到这一步，接下来就是「自己技术栈里危险的默认设置」和「不在已公开漏洞（CVE）上落后的机制」了。别着急，一个一个来。
接着读
- 术语：.env 是什么 / CVE 是什么 / RCE 是什么
- 防护：在虚拟主机上别让 .env 被公开 / Next.js 的 CVE 跟进
- 事故：API key 被偷走后遭盗刷的事
- 事故：用偷来的 key 导致账号被封的事
FAQ
Q想学安全，该从哪儿开始？
先从『不让秘密的值（.env 和 API key）泄露出去』开始。很多真实事故都是从这里发生的。不公开、不提交到 git、泄露就全部更换、偶尔自查一下，做好这 4 点就能挡住绝大多数事故。
QAPI key 泄露后，具体会发生什么？
别人能冒充你去使用外部服务。常见的就是盗刷（用你的账单跑大量调用），以及读写数据。泄露的 key 往往会有时间差地被转卖、滥用。
Q.env 可以放进 git 吗？
不可以。要在 .gitignore 里加上 .env*，只共享把值清空后的 .env.example。一旦提交过，即便之后删掉，也能从 git 的历史里恢复出来。