cookie 的 path 属性仅控制浏览器自动发送范围，不提供访问权限控制；真正的权限校验必须由服务端完成，需结合身份验证、角色检查及资源授权等逻辑，并配合 secure、httponly、samesite 等安全属性。

Cookie 的 path 属性本身**不控制访问权限**，它只控制浏览器在什么路径下自动发送该 Cookie。真正的访问权限控制必须由服务器端逻辑实现，path 只是配合这一逻辑的前端约束机制。

path 属性的作用：限定 Cookie 的作用范围

path 指定一个 URL 路径前缀，浏览器仅在请求该路径或其子路径时，才将 Cookie 自动附加到 HTTP 请求头中（Cookie: 字段）。它不是安全边界，也不阻止手动读取或篡改。

• 例如：Set-Cookie: auth=abc123; path=/admin → 浏览器只在请求 /admin、/admin/users、/admin/settings?x=1 等路径时发送该 Cookie
• 但不会在 /api、/public 或根路径 / 下发送
• path=/（默认值）表示整个站点都可访问；path=/user 不等于 path=/users（注意末尾斜杠）

为什么不能靠 path 实现权限控制？

因为 path 完全由客户端（浏览器）执行，且可被绕过：

• JavaScript 仍可通过 document.cookie 读取同源下所有未标记 HttpOnly 的 Cookie，无论 path 是什么
• 攻击者可构造恶意页面，诱导用户访问 /admin/xxx，从而触发带 Cookie 的请求（如果已有合法登录）
• 服务端若仅检查 Cookie 是否存在，而不校验用户身份、角色、资源归属等，就会误判权限

正确做法：path + 服务端鉴权协同使用

把 path 当作“辅助隔离层”，核心权限判断始终落在服务端：

• 设置合理 path：为不同功能域分配专属 Cookie 路径，降低误用风险。例如：
  Set-Cookie: session_id=...; path=/dashboard
Set-Cookie: api_token=...; path=/api/v2
• 服务端强制校验：每次收到请求，无论路径如何，都应解析并验证 Cookie 对应的身份凭证（如 JWT、session ID），再结合当前请求路径、HTTP 方法、用户角色、资源 ID 做细粒度授权（如 RBAC 或 ABAC）
• 搭配其他安全属性：启用 Secure（仅 HTTPS）、HttpOnly（防 XSS 窃取）、SameSite=Lax/Strict（防 CSRF），让 path 发挥更大协同价值

常见误用与建议

避免以下典型错误：

• ❌ 在 /admin 设置 Cookie 后，就认为访问 /admin/delete-user 无需再查管理员角色
• ❌ 把敏感 Token 放在 path=/ 下，却依赖前端 JS 判断路径来决定是否调用接口（极易被绕过）
• ✅ 推荐：所有后端接口统一做中间件鉴权，path 仅用于组织 Cookie 分发逻辑，提升可维护性