停止使用 AllowAnyOrigin()

Source: Dev.to

AllowAnyOrigin() 可能看起来是解决 CORS 错误的快速办法，但它会悄悄打开通往严重安全风险的大门。许多开发者在不了解其会如何让 API 暴露给不受欢迎的访问的情况下使用它。在真实的应用场景中，这一行代码可能导致数据、身份验证以及用户信任受到危害。

常见错误 – 使用 AllowAnyOrigin()

• 允许任何网站访问你的 API，包括恶意域名。
• 暴露本应仅供自己前端使用的敏感端点。
• 与 Cookie 或身份验证头一起使用时，会增加 CSRF 攻击的风险。
• 常被用来快速修复 CORS 错误，随后在投产前被遗忘。
• 违背最小权限原则，授予的访问权限超出必要范围。
• 一次配置错误就可能导致数据泄露、API 被滥用以及安全漏洞。

安全环境 – 基于环境的设置

开发配置 (DevConfig)

• 仅允许受限的本地来源，如 localhost，以加快开发和测试。
• 使用宽松的 CORS 规则，但不暴露真实的生产数据。
• 将环境变量分离，避免意外访问生产环境。
• 明确标记此配置为仅用于开发。

生产配置 (ProdConfig)

• 仅允许受信任的域名（例如你的官方前端 URL）。
• 在任何情况下都绝不能在生产环境使用 AllowAnyOrigin()。
• 为头信息、方法和凭证启用更严格的规则。
• 随着应用的成长，定期审查并更新允许的来源。

中间件位置 – 重要

• CORS 中间件必须在身份验证和授权之前注册，才能正常工作。
• 放置位置错误会导致即使配置正确也缺少 CORS 头。
• 如果未正确处理预检 (OPTIONS) 请求，浏览器会阻止请求。
• 将 CORS 放在管道太后会产生看似身份验证或 API 问题的混乱错误。
• 正确的中间件顺序可确保在所有环境中行为一致。

结论

仅有 CORS 配置还不够——中间件放置的位置同样重要。一个安全且位置恰当的 CORS 设置可以避免不必要的错误，提高可靠性，并确保你的 API 在开发和生产环境中都能如预期般运行。