将上线站点代码上传至GitHub公开仓库的安全问题咨询

• 代码提交历史敏感信息泄露：哪怕你最新版本已经删除了所有敏感内容，之前私有仓库的提交历史里如果有过硬编码的API密钥、旧后台路径、内部配置、测试账号，直接推送完整历史到公开仓库的话，所有人都能查到历史记录里的敏感内容。千万不要直接把包含完整提交历史的私有仓库直接推送公开，要么重新初始化git仓库只推最新的干净版本，要么用git filter-repo这类工具彻底擦除历史里的敏感内容后再公开
• Django配置残留风险：检查settings.py是否存在DEBUG = True的配置，生产环境开启DEBUG会直接暴露项目结构、错误栈甚至部分环境变量值；同时确认Django的SECRET_KEY已经完全移到ENV文件，没有在代码里留过任何硬编码的旧值
• 测试/调试接口遗留：排查是否存在开发阶段临时加的未授权测试路由、调试接口、硬编码的测试账号凭证，这类内容如果没清理，公开代码后攻击者可以直接按照代码里的路径构造请求访问
• 本地数据泄露：确认项目目录下没有把测试用sqlite数据库文件、用户上传的样本文件、本地配置备份文件加入git追踪，这类文件一旦公开会有数据泄露风险
• 依赖漏洞暴露：你公开的requirements.txt会暴露所有依赖包的版本，如果用到的版本有已知高危漏洞，攻击者可以直接定位漏洞点对你的线上站点发起攻击，公开前建议先做一轮依赖漏洞扫描修复

• 优先用单仓库多分支方案替代双仓库：不需要维护两套仓库增加负担，你可以把公开仓库的main分支作为对外展示的干净生产分支，内部开发、调试的内容都放在私有dev分支，每次要同步公开内容时，把dev分支剔除敏感信息后的内容合入main再推送即可，操作成本很低
• 配置提交前敏感信息校验：本地安装pre-commit钩子，每次提交代码前自动扫描是否存在硬编码的密钥、内部路径、服务器IP这类敏感内容，避免不小心把敏感信息提交到公开分支
• 公开代码与线上部署解耦：如果不想迁公共托管平台，不需要强行迁移，只要保证公开代码里没有任何可以直接定位到服务器漏洞、登录凭证的内容即可，额外可以给后台路由加服务器IP白名单限制，哪怕攻击者知道后台路径也无法访问
• 规范公开分支提交信息：公开分支的提交信息只写功能更新、问题修复这类通用内容，不要提到线上部署细节、服务器配置调整、运维操作这类信息，避免给攻击者传递有效信息
• 定期审计公开仓库：每次更新公开分支后检查一遍提交内容，每季度做一次全仓库的敏感信息排查，避免历史提交中遗漏敏感内容

内容的提问来源于stack exchange，提问作者ramseylove