Python后端项目上线前的安全合规检查，最怕的不是漏掉某一项，而是把检查做成了形式化的清单打勾。真正有效的自查，应该从攻击面、数据流、配置管理和应急响应四个维度切入，每一项都能对应到具体的代码或部署配置，而不是停留在“建议开启HTTPS”这种空话上。

依赖与供应链安全是第一个硬指标

绝大多数Python项目的安全事故不是发生在自己写的代码里，而是发生在第三方依赖里。上线前第一件事是锁定依赖版本，生成精确的锁文件。对于pip用户，requirements.txt里如果只写包名不写版本，等于把生产环境的稳定性交给发布当天的网络状态。正确做法是使用pip freeze生成完整版本，或者使用pip-tools、Poetry、Pipenv这类工具维护锁文件。

pip freeze > requirements-lock.txt

光锁定版本还不够，需要扫描已知漏洞。可以使用pip-audit对当前环境做一次CVE级别的检查，它会比对PyPA维护的漏洞数据库。如果项目使用了大量自建镜像源，还要确认镜像源同步策略不会导致漏洞库滞后。对于关键业务依赖，建议在requirements中固定哈希值，防止镜像源被篡改后下发恶意包。

pip-audit -r requirements-lock.txt

另外要检查依赖中是否包含不必要的开发包。很多团队会把pytest、black、debugpy这类工具直接打进生产镜像，这不仅增大镜像体积，还扩大了攻击面。生产依赖和开发依赖必须分离，构建镜像时使用多阶段构建，只把运行时必需的包复制到最终镜像。

敏感信息管理必须做到零硬编码

数据库密码、API密钥、JWT签名密钥、第三方服务凭证，这些信息只要出现在代码仓库里，就视为已经泄露。自查时用git grep扫描整个提交历史，而不是只看当前工作区。很多开发者以为删掉就安全了，但git历史里仍然完整保留。

git grep -n "password\|secret\|api_key\|token" $(git rev-list --all)

更彻底的做法是引入秘密扫描工具，比如trufflehog或gitleaks，在CI阶段自动拦截。对于已经泄露的密钥，不能只删除，必须立即轮换，因为无法确定是否已经被外部获取。生产环境的敏感信息应该通过环境变量注入，配合密钥管理服务使用。如果使用Docker部署，不要在Dockerfile里写ENV敏感值，也不要在docker-compose.yml里明文写密码，应该引用外部.env文件或使用Docker secrets。

配置文件方面，建议将配置分为基础配置和环境配置，环境配置通过环境变量覆盖。对于必须落盘的敏感配置，文件权限必须设置为600，并且所属用户为运行进程的专用用户，不能是root。

Web框架层面的安全加固要具体到中间件

无论用Flask、Django还是FastAPI，上线前都要检查几个核心中间件是否配置正确。首先是安全响应头，包括Content-Security-Policy、X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security。这些头不能只靠Web服务器加，应用层也要设置，因为反向代理配置可能被绕过。

Django项目要检查SECURE_SSL_REDIRECT、SESSION_COOKIE_SECURE、CSRF_COOKIE_SECURE这几个参数是否在生产环境为True。SESSION_COOKIE_HTTPONLY必须开启，防止XSS窃取会话。对于CSRF保护，要确认所有状态变更请求都经过CSRF中间件，特别是AJAX请求，不能因为前端用了fetch就忽略CSRF token的传递。

Flask项目要检查WTF_CSRF_ENABLED是否开启，SESSION_COOKIE_SAMESITE是否设置为Lax或Strict。FastAPI项目由于异步特性，要特别注意CORS配置，不能图省事直接允许所有来源。allow_origins里写*的同时如果allow_credentials为True，等于把认证接口暴露给任意网站。

文件上传功能是重灾区。上传目录必须在Web根目录之外，文件名必须重新生成，不能直接使用用户提供的文件名。文件类型校验不能只依赖扩展名，要检查MIME类型和文件头。如果上传的是图片，建议用Pillow重新编码一次，可以消除大部分恶意载荷。上传文件的大小必须在应用层限制，不能只依赖Nginx的client_max_body_size。

数据库与ORM层的安全细节

SQL注入在ORM时代并没有消失，只是换了形式。自查时要重点检查所有使用raw SQL、extra、annotate的地方，确认参数化查询没有被字符串拼接替代。Django的extra方法尤其危险，很多开发者为了图方便直接拼接字段名。如果确实需要动态字段名，应该使用白名单校验，而不是直接插入字符串。

数据库连接账号要遵循最小权限原则。应用账号只授予SELECT、INSERT、UPDATE、DELETE权限，DDL权限只属于迁移专用账号。迁移操作应该与运行时分离，生产环境的应用进程不应该有建表、改表权限。数据库端口不应暴露在公网，应用与数据库之间通过内网通信，必要时使用VPC安全组限制来源IP。

对于敏感数据，数据库层面要考虑字段级加密。用户的手机号、身份证号、银行卡号等信息，不能明文存储。应用层加密可以使用cryptography库的Fernet对称加密，密钥从密钥管理服务获取。数据库备份文件同样包含敏感数据，备份文件必须加密存储，并且访问权限独立于应用权限。

日志与监控中的合规红线

日志是安全审计的重要依据，但日志本身也可能成为泄露源。自查时要检查日志格式中是否包含敏感字段，比如密码、token、完整身份证号、完整银行卡号。很多框架的默认错误日志会把请求参数完整打印出来，如果请求参数里包含密码字段，就会直接落盘。

建议在日志中间件中对敏感字段做脱敏处理，密码字段统一替换为*，手机号保留前3后4，中间打码。日志级别也要区分，生产环境不应开启DEBUG级别，否则ORM会输出完整的SQL语句，其中可能包含敏感查询条件。

日志的保留周期和访问权限同样重要。日志文件应设置合理的轮转策略，避免无限增长。访问日志的权限应限制在运维和安全人员范围内，不能所有开发者都能查看生产日志。如果使用集中式日志平台，要确认日志传输链路是否加密，日志存储是否有访问审计。

认证与授权要覆盖接口级粒度

很多项目的认证做到了，但授权只做到了页面级。用户登录后能看到菜单，但直接调用API接口时，后端没有校验该用户是否有权限访问这个资源。自查时要逐个检查API端点，确认每个端点都有明确的权限要求。对于水平越权，要验证资源归属关系，比如用户只能访问自己的订单，不能通过修改ID访问他人订单。

JWT的使用要特别注意。签名算法不能设置为none，密钥强度要足够，HS256密钥至少256位。JWT的过期时间要合理，不能设置成永久有效。对于需要立即失效的场景，比如用户修改密码后，要有token黑名单机制或者使用短期token配合refresh token。

密码存储必须使用强哈希算法。bcrypt、argon2、scrypt都是可接受的选择，MD5和SHA1绝对不能用于密码存储。Django默认使用PBKDF2，这是可以接受的，但要确认迭代次数足够高。密码重置流程要防止枚举攻击，无论用户是否存在，返回的信息应该一致。

部署架构与网络安全

应用进程不能以root用户运行。容器化部署时，Dockerfile中要创建专用用户并切换过去。文件系统权限要收紧，应用目录只读，只有日志目录和上传目录可写。容器的基础镜像要选择官方维护的精简镜像，比如python:3.12-slim，而不是使用latest标签或来源不明的镜像。

网络层面，应用服务器只开放80和443端口，管理端口如SSH、数据库端口、调试端口必须限制来源IP。如果使用云服务，安全组规则要默认拒绝，只放行必要的入站流量。出站流量也要限制，防止服务器被入侵后成为跳板机。

HTTPS配置不能只停留在证书有效。要检查TLS版本，至少使用TLS 1.2，建议TLS 1.3。弱加密套件要禁用，比如RC4、3DES。HSTS头要设置合理的max-age，建议至少半年。证书的私钥文件权限必须为600，且不能放在Web可访问目录下。

数据合规与隐私保护

如果项目涉及用户个人信息，需要确认是否满足相关法律法规要求。用户数据的收集要有明确告知和同意机制，隐私政策要说明收集哪些数据、用于什么目的、保存多久。用户要求删除数据时，系统要能真正删除，而不是仅做逻辑删除标记。

数据跨境传输要特别谨慎。如果服务器部署在境外，而用户数据来自境内，可能涉及数据出境安全评估。即使服务器在境内，使用第三方服务如CDN、日志分析、邮件发送服务时，也要确认这些服务商的数据处理地点和方式。

对于日志中的IP地址，如果用于分析，建议做匿名化处理，比如只保留前两段。Cookie中的用户标识如果用于追踪，要告知用户并取得同意。第三方统计脚本的引入要评估数据流向，不能默认信任所有第三方服务。

上线前的最后一道检查：应急响应准备

安全合规自查的最后一个环节，是确认出事后能快速响应。备份策略要验证过恢复流程，不是有备份就万事大吉。数据库备份要定期做恢复演练，确认备份文件完整可用。应用代码要有版本回滚能力，部署流程要支持一键回滚到上一个稳定版本。

监控告警要覆盖关键指标：CPU、内存、磁盘、错误率、响应时间、异常登录、暴力破解尝试。告警阈值要合理，避免告警疲劳。值班人员要明确，告警发生后有清晰的升级路径。

安全事件的处理流程要提前定义：谁负责判断事件等级，谁负责切断攻击路径，谁负责通知用户，谁负责对外沟通。这些不能等到出事后再讨论。对于涉及用户数据泄露的事件，要了解相关法律法规要求的通知时限，提前准备通知模板。

上线不是终点，安全合规是一个持续的过程。每次代码变更、每次依赖升级、每次配置修改，都可能引入新的风险。将上述检查项固化到CI/CD流程中，让安全检查成为每次部署的必经环节，才能真正把风险挡在生产环境之外。