我对我的侧边项目进行了安全审计 —— 以下是我的发现
我最近审计了所有的侧边项目。我检查了我的 FastAPI 后端、Telegram 机器人和 Web 应用。我原以为自己很谨慎。
但我错了。
我发现了已经部署到生产环境的真实漏洞。这些不是理论上的问题，而是在追求开发速度时犯下的错误。
以下是我发现的主要问题以及修复方法：
- 条件式身份验证 我写的代码仅在存在密钥（secret）时才检查 API 密钥。如果我忘记在环境变量中设置密钥，检查就会被完全跳过。这导致我的 API 对所有人开放。
- 修复：永远不要让身份验证变成条件式的。如果密钥缺失，应用程序应该抛出错误并停止运行。
- Git 历史记录中的密钥泄露
我在 Git 历史记录中发现了旧的 API 密钥。虽然我后来把它们移到了
.env文件中，但 Git 会永久保留代码的每一个旧版本。
- 修复：将任何提交到 Git 的密钥视为已泄露。立即撤销该密钥。使用
git-filter-repo等工具清理你的历史记录。
- 残留的调试端点 我在生产环境中留下了可以显示数据库配置和系统设置的端点。这些在开发阶段很有用，但在实际运行环境中非常危险。
- 修复：将“移除调试端点”添加到你的部署清单中。
- 过于详细的错误信息 我之前会将原始的系统错误返回给用户。这些错误会泄露你的文件路径、数据库类型和库版本。攻击者可以利用这些数据来针对你的系统。
- 修复：在内部记录完整的错误日志供自己查看。向客户端返回通用的 "Internal Server Error" 消息。
- 通过
innerHTML导致的 XSS 攻击 我在前端使用innerHTML来渲染用户数据。这允许攻击者向你的网站注入脚本。
- 修复：始终对数据进行消毒（sanitize），或者使用
textContent代替innerHTML。
- 缺乏速率限制 我有一些端点在没有限制的情况下调用昂贵的 AI 模型。一个用户可能在几分钟内就产生巨额账单。
- 修复：身份验证用于阻止未经授权的用户，而速率限制用于防止已授权的用户滥用你的系统。两者缺一不可。
- 过于宽松的 CORS 设置
我在中间件中使用了
allow_origins=["*"]。这允许任何网站向你的 API 发起请求。
- 修复：在生产环境中仅允许你特定的域名。
- 文件泄露 我编写的代码会创建临时文件，但如果进程崩溃，则无法删除这些文件。这些文件会永远留在你的服务器上。
- 修复方案：使用
try-finally块，以确保即使发生错误，文件也能被删除。
安全问题很少是故意的。它们往往是“我以后再修”这种心态的结果。而“以后”永远不会到来。
从第一天起就将安全性融入你的工作流中。在提交和部署之前检查你的代码。
来源：https://dev.to/justjinoit/i-audited-my-own-side-projects-for-security-issues-heres-what-i-found-1ahb