Day 021 · 独立开发者，也需要自己的安全清单

以前在公司工作时，很多安全措施几乎是隐形的。

公司邮箱、设备管理、权限审批、代码审查、生产环境、用户数据，都有人制定规则。一个人做产品后，这层保护突然消失了。

域名、代码、数据库、API、支付、用户信息，都集中在自己手里。你不只是产品经理、设计师和开发者，也变成了自己的 IT、安全和事故响应团队。

而独立产品最常见的安全问题，往往不是什么复杂攻击，只是一个低级错误被快速放大。

1. 把 API Key 当作权限，而不是一串字符

API Key、数据库密码、云服务 credential、支付 secret，本质上都是一份授权。

拿到它的人，可能可以替你调用服务、产生费用、读取数据，甚至修改或删除资源。

所以我现在会遵守几个底线：

.env 也不是保险柜。它只是避免把 secret 直接写进代码。文件如果被上传、共享、记录到日志，仍然可能泄露。

还有一个很重要的原则：

如果 secret 已经提交到 Git，后来把文件删掉并不够。它可能仍然存在于 Git 历史中。

这时第一件事不是“藏好痕迹”，而是立即 revoke 或 rotate，换一份新的 credential。

对独立产品来说，最重要的账号未必是产品后台，而是：

其中一个被拿走，都可能让你失去整个产品的控制权。

这些账号至少应该使用不同密码、开启 MFA，并妥善保存 recovery codes。

尤其是主邮箱。很多账户都可以通过邮箱重置密码，它其实是所有权限的总入口。

3. 不要只问“文件能不能上传”

上传到第三方服务，不一定等于文件公开在互联网上。

但它意味着信息已经离开了你完全控制的环境。

我现在更愿意问：

独立开发时，生产数据库、用户资料、后台截图和真实日志尤其需要谨慎。

为了让 AI 帮忙 debug，直接把整份生产数据、完整日志或用户信息贴进 chat，通常不是唯一选择。

很多时候，只保留报错结构、字段名称和最小复现样例就够了。

AI agent 可以读取代码、运行命令、修改文件、访问 GitHub，甚至连接邮件、云盘和数据库。

这让一个人做产品的效率提高了很多，也意味着一个错误动作可以走得更远。

授权之前，我会考虑：

重点不是假设工具一定会出错，而是即使出错，也不要让一次错误带走全部资产。

5. 不只防止事故，也要准备恢复

没有任何系统能保证永远不出问题。

所以安全还包括：

真正实用的安全，不是追求零风险，而是控制一次事故的影响范围。

我会至少检查这 12 件事：

一个人做产品，意味着很多东西都可以自己决定。

但自由的另一面是：没有人会自动替你检查这些边界。

安全不一定是产品里最令人兴奋的部分。

可一旦出问题，它很可能突然变成最重要的部分。