开发者们承受着 sprint 截止日期和功能需求的压力。性能调优和 UI 润色往往能获得赞誉，而安全通常被堆积在待办事项（backlog）中，静静地等待轮到它。这种等待是一个错误。自动化机器人全天候扫描互联网，探测泄露的密钥、注入点和薄弱的身份验证。数据泄露已成为科技新闻中的背景噪音，但对于负责该业务的团队来说，后续的清理工作是极其惨烈的。好消息是，编写安全的代码并不需要密码学博士学位。它只需要将一些良好的习惯融入到你的日常工作流中。以下是五项能够切实保护你的用户和系统的实践。

保护你的身份验证

许多团队都曾想过亲手打造一套自定义登录系统：一个用户表、一个密码列、一个 JWT 生成器。这看起来很直接，直到你意识到你现在必须负责会话管理、令牌轮换、暴力破解防护以及安全的密码重置。大多数团队应该停止从零开始构建这些功能。通过 OAuth 2.0 或 OpenID Connect 将身份验证交给成熟的身份提供商，可以从你的代码库中消除整类风险。你可以继承那些经过数千名工程师实战检验并经过更广泛安全社区审查的协议。

话虽如此，如果你必须亲自处理密码，请务必谨慎对待。使用 bcrypt 或 Argon2 对每一个密码进行哈希处理。这些算法被设计得刻意很慢，这种缓慢可以遏制那些窃取了你的数据库并试图离线破解密码的攻击者。永远不要以明文形式留下密码。不要出现在日志中，不要出现在崩溃报告中，不要出现在任何地方。

多因素身份验证（MFA）不再是可选项。密码会泄露，网络钓鱼也屡见不鲜。无论是 TOTP 应用还是硬件密钥，增加第二个验证因素都能显著降低账号被接管的概率。

当你签发会话令牌或 JWT 时，请将其存储在带有 HttpOnly 和 Secure 标志的 Cookie 中。HttpOnly 标志可以阻止 JavaScript 读取 Cookie，从而抵消许多跨站脚本（XSS）攻击。Secure 标志则确保浏览器仅通过 HTTPS 传输 Cookie。不要将 JWT 存放在 localStorage 中。虽然这看起来很方便，但你网站上的任何 XSS 漏洞都会让攻击者立即获取用户的令牌。

将 OWASP Top 10 作为你的基准

OWASP Top 10 不是理论考试的大纲，它是 Web 应用程序实际遭受攻击的最常见方式的目录。忽视它就像因为相信自己的反应能力而无视交通标志一样。

SQL 注入在首次被记录几十年后，依然在困扰着生产环境中的数据库。修复方法很简单，但需要自律。永远不要将用户输入直接拼接进查询字符串。请使用参数化查询，或者使用像 Prisma 这样能为你处理转义的 ORM。数据库驱动程序会将代码与数据分离，因此恶意输入无法重写你的查询逻辑。

跨站脚本攻击（XSS）利用未经过滤的用户输入大行其道。如果你的应用程序会渲染用户提交的任何内容，请务必先进行清理（sanitize）。现代框架通常默认会对输出进行转义，但自定义组件和 dangerouslySetInnerHTML 风格的 API 可能会绕过这些防护措施。请明确界定你信任的内容。

跨站请求伪造（CSRF）会诱骗浏览器执行其不应执行的操作。可以通过在表单中嵌入 anti-CSRF 令牌，并为 Cookie 设置 SameSite 属性来缓解这一问题。SameSite=Lax 或 Strict 会告知浏览器在跨源请求期间不要发送 Cookie，从而有效阻止大多数 CSRF 攻击。

应用最小权限原则

并非每个用户都需要管理员权限，也并非每个微服务都需要对数据库的 root 访问权限。最小权限原则意味着仅授予特定任务所需的精确访问权限，不多也不少。

从你的应用程序数据库用户开始。如果你的后端只需要读写行，请移除其删除表（drop tables）、修改架构（alter schemas）或创建新数据库的权限。当攻击者攻破你的应用程序时，这些受限的权限会成为一道屏障。他们可能会窃取数据，但无法通过一条命令就抹除你的基础设施。

将同样的思路应用到你的云环境中。AWS IAM 角色、Google Cloud 服务账号和 Azure 托管身份都应缩小到单个操作的范围。一个仅部署静态资源的 CI/CD 流水线不需要启动昂贵计算集群的权限。审查这些