登录：谁在用，凭什么

一句话

**藏起来的按钮拦不住任何人。**真正的门锁在后端，不在界面上。

很多人把这两件事混成一件，然后漏掉后面那件：

	英文	回答什么问题	举例
鉴权	Authentication	你是谁？	登录、验证码、第三方登录
授权	Authorization	你能干什么？	普通用户不能删别人的帖子

**绝大多数事故出在第二件。**登录做了，但「登录之后你能碰哪些东西」没做。

结果就是：任何一个注册用户，改个 URL 里的 id，就能看到别人的数据。

你让 AI 做一个「我的订单」页面。它会给你：

前端：登录后，请求 /api/orders?userId=当前用户
后端：收到 userId，把该用户的订单返回

能跑。也完全不设防。

因为 userId 是前端传的——用户改一下就变成了别人。后端老老实实照办。

正确的做法只差一句话：

后端：不要相信前端传来的 userId。
     从登录凭证里取出「你是谁」，用那个去查。

「不要相信前端传来的身份」——这一句是整节的核心。

所有需要登录的接口，用户身份必须从服务端的登录会话里取，绝不接受前端传来的用户 id。每个接口都要检查「当前这个人有没有权限碰这条数据」，不只是检查「有没有登录」。

再加一句验收：

做完之后，告诉我用 A 用户的身份去请求 B 用户的数据会发生什么。

它答不上来，或者答「前端不会这么请求」，就是没做。

这是本节唯一的「照做就行」建议：不要让 AI 从零给你写一套账号密码系统。

密码怎么存、怎么加盐、重置流程怎么防劫持、会话怎么过期、怎么防撞库——这些每一条都有坑，而且坑的代价是用户的密码。

用现成的。Supabase Auth、Auth0、Clerk、各家云的身份服务，都有免费额度，几行代码接上，安全部分是他们的事。

准备两个账号（A 和 B），然后：

返回了 B 的数据 = 有 IDOR，必须修。 返回 403 / 404 = 正确。

再做一遍不登录的版本：

curl -i https://你的站/api/需要登录的接口

不是 401 或 403，就是漏了。