授权Authorization
把地址里的询盘编号换一下，为什么必须仍然拦得住？
授权（Authorization，AuthZ）是依据规则决定某个主体能否对某项资源执行某种动作。权限可结合角色、资源归属、组织与其他条件判断，敏感操作必须在可信服务端落实。
不只问你是谁，还要问这份资料是不是你能看的、这件事是不是你能做的。知道地址不等于获得许可。
像一排带锁的档案柜：拿到员工工牌只能证明身份，具体能开哪一格，还取决于分配的钥匙。
类比到这里为止：软件权限可以细到单条记录和单次动作，并可能随归属变化。角色名字本身不会自动变成正确规则。
销售甲可看自己负责的线索，主管按既定范围看团队线索。导出、修改和删除可另有要求，不能因为能阅读就顺带放开。
对一条客户记录作判断
- 主体
- 从已验证的会话得到用户，而不是信任请求正文里自报的管理员身份。
- 资源
- 在服务端核对询盘的归属与组织，不能只检查编号格式。
- 动作
- 查看、修改、导出和删除分别对应什么许可？
- 拒绝与记录
- 条件不满足就不返回敏感数据，适当记录拒绝原因供受限排查。
用相邻身份验证边界
至少对比未登录、自己的记录、他人的记录与不同角色。测试要实际请求受保护入口，而不只是检查按钮是否出现。
下面的权限演示只计算页面内虚构规则，没有用户登录系统。它用于理解授权判断，不能复制到生产中替代完整认证与授权实现。
把地址里的询盘编号换一下，为什么必须仍然拦得住？
可以操作，也可以重试。数据为虚构示例，不连接真实业务系统。
正在准备当前演示，正文可以继续阅读。
继续看项目应用与交付检查
授权 在项目中负责什么
- 什么时候用
- 多人共享客户、课程管理或工具连接能力，需要避免越权读写时。
- 它解决什么
- 把可用能力限制在完成任务需要的范围，防止直接请求绕过界面限制。
- 它不负责什么
- 隐藏按钮、难猜编号与提示词提醒都不能替代后端校验。默认允许后再到处补拒绝，容易遗漏入口。
- 放进真实项目
- 销售只能修改自己负责的询盘，管理员才可以导出全部客户资料。
身份通过后，还要看这件事是否轮到你办
销售 A 只能看自己负责的客户；主管能看团队；财务能看报价，却不该修改客户来源。
- 01
为角色和资源归属写授权规则。
- 02
每个敏感接口都在服务端再次校验。
- 03
记录拒绝和高风险操作，方便审计。
主体 × 资源 × 动作，每次都查实际范围。
容易混淆的地方
角色是组织权限的方法，权限才是实际动作与范围。已登录用户也可能得到拒绝响应。
销售甲把 URL 里的询盘编号换成销售乙的编号，接口就返回了乙的客户资料。漏洞在哪？
登录以后，也不能默认什么都能看
三个销售共用线索系统。登录正常，但每个人都能导出全部客户、修改别人的跟进记录。
你可以这样告诉 AI Agent
我在处理这件事：销售只能修改自己负责的询盘，管理员才可以导出全部客户资料。请以“授权”为主线，先说明它在这里负责什么、不负责什么；再列出必要输入、建议动作和可验证结果。用外贸独立站的业务语言回答，不确定的信息标为待确认。
内容依据与延伸
本站用原创中文解释把专业概念映射到外贸独立站；定义和机制继续以官方资料为准，业务例子再回到 外贸独立站询盘优化实战 验证。
本站整理说明：原创整理：Web 开发、产品设计、AI 协作与外贸独立站实践