后端架构师在聊方案时，最怕的就是把所有输入都当成“好心人”提供的。

很多所谓的安全面试题其实是在考一个直觉：当你描述一个系统设计时，能不能下意识地想到哪里会被人钻空子。在公司推行 AI 工作流或者升级后端架构时，我发现很多开发习惯性地认为只要过了 Auth 校验就安全了，但实际上，认证（Authentication）没问题并不代表授权（Authorization）没问题。

一个典型的坑就是过度信任客户端传来的 ID。比如某个接口通过 URL 传 ID 查记录，代码逻辑是“检查用户是否登录 → 登录了 → 返回记录”。这在逻辑上是通的，但安全上是崩的，因为用户 A 登录后只要改个 ID 就能看到用户 B 的数据。这种授权漏洞在实际业务中比认证漏洞常见得多。

关于密码存储，现在标准的实操应该是用 Argon2 或 bcrypt 这种故意设计得很慢、且内存密集型的哈希算法。这里有个关键点：慢才是核心竞争力。因为真正的威胁是数据库被拖库后的离线暴力破解，而不是登录时的实时请求。而且为了防止通过响应时间推测用户是否存在，登录失败的路径必须保证恒定时间（Constant Time）。

在处理 Session 和 Token 时， stateless token（如 JWT）虽然解决了扩展性问题，但代价是无法立即撤回。成熟的落地方案通常是“短效 Access Token + 长效 Refresh Token”，仅在极高风险的路径上引入黑名单校验。

至于最经典的注入问题，很多人习惯说“转义”，但更专业的说法应该是“分离”。参数化查询（Parameterized Query）本质上是将指令和数据分开传输，让数据库根本不会把用户输入当成 SQL 指令去解析，这比任何过滤规则都要可靠。

// ❌ 错误示范：字符串拼接，极易被注入
const query = "SELECT * FROM users WHERE username = '" + userInput + "'";
db.query(query);

// ✅ 正确示范：参数化查询，实现结构化分离
const query = "SELECT * FROM users WHERE username = ?";
db.query(query, [userInput]);