Django ORM 不自动脱敏，敏感字段泄露主因是未主动裁剪字段。应使用 only()、defer()、Serializer 字段白名单等显式控制输出，而非依赖 ORM 自动安全。
直接硬编码或明文传输数据库查询结果，不是“未加密导致泄露”，而是根本没做敏感数据保护。Django ORM 本身不加密字段，也不自动脱敏——它只负责把 Python 对象映射成 SQL。所谓“查询未加密”是个常见误解，真正的问题出在数据落地、传输、日志和展示环节。
为什么 SELECT * FROM user 会泄露密码字段？
因为 Django 的 User 模型默认包含 password 字段（已哈希），但如果你用 values()、values_list() 或序列化整个模型实例，又没显式排除敏感字段，就可能把 password、last_login、is_staff 等字段一并返回给前端或写入日志。
- 错误示例：
User.objects.values()→ 返回所有字段，含password（虽然哈希值本身不等于明文密码，但属于认证核心凭证，不应暴露） - 更危险的是自定义模型里加了
api_key、ssn、id_card等字段，且未设editable=False或db_column隐藏 - 调试时用
print(user.__dict__)或logging.info(user)，会把所有字段（包括_password、_state）打出来
如何安全地控制 QuerySet 字段输出？
别依赖 ORM “自动安全”，要主动裁剪。关键不是加密查询，而是限制字段可见性。
- 用
only()显式声明需要的字段：User.objects.only('id', 'username', 'email') - 用
defer()排除敏感字段：User.objects.defer('password', 'last_login', 'date_joined') - 避免
values()无参数调用；带参数时明确列出字段：User.objects.values('username', 'email') - 序列化前做字段白名单检查：Django REST Framework 中，在
Serializer里定义fields = ('id', 'username', 'email')，不要用__all__ - 自定义模型方法中，禁止返回
self.__dict__；改用model_to_dict(instance, fields=['id','username'])
哪些地方最容易漏掉脱敏逻辑？
敏感字段泄露往往不在主业务逻辑，而在辅助路径：日志、异常堆栈、管理后台、API 调试响应、缓存键生成。
立即学习“Python免费学习笔记（深入）”；
- Django Admin 默认显示所有字段；需重写
list_display并避开password，或用readonly_fields隐藏 -
LOGGING配置中若启用了django.db.backends的DEBUG级别，SQL 查询语句（含参数）会被完整记录 → 确保生产环境关闭LOGGING['loggers']['django.db.backends']['level'] = 'WARNING' - 自定义中间件捕获异常时，别把
request.POST或request.GET全量打印；用request.POST.dict()前先 pop 掉'password'、'token' - 使用
cache.set('user_profile_123', user)时，user 是模型实例 → 缓存的是未脱敏对象；应改为cache.set('user_profile_123', {'id': user.id, 'username': user.username})
加密字段真有必要吗？什么时候该上？
字段级加密（如 django-encrypted-model-fields）是高成本方案，只适用于极少数场景：比如必须落库的身份证号、银行卡号，且合规要求强制加密存储。
- 它不解决传输或展示泄露，只防数据库被拖库后明文读取
- 加密后无法索引、无法 LIKE 查询、无法在数据库侧做聚合，性能损耗明显
- 密钥管理引入新风险：密钥若硬编码或存在环境变量中，仍可能泄露；推荐用 KMS（如 AWS KMS）托管
- 绝大多数场景下，优先用字段裁剪 + 传输层 TLS + 应用层权限校验，比加密字段更轻量、更可控
真正容易被忽略的，是那些“看起来只是调试用”的地方：比如一个临时写的 manage.py 命令导出用户列表，或者 API 返回 400 错误时把整个 request body 打进响应体——这些路径从不走主业务校验逻辑，却恰恰是攻击者最爱试探的盲区。
