HTML hidden属性仅视觉隐藏，无法替代后端权限控制；真实权限必须由后端校验并返回结构化数据，前端仅据此条件渲染；display与visibility均不安全，但影响布局不同；自定义标签仅为扫描锚点，不具权限逻辑；接口层鉴权缺失将导致绕过风险。
HTML hidden 属性不能替代权限控制
它只是视觉隐藏，不阻止用户通过 DevTools 删除该属性、修改 DOM 或直接请求后端接口。hidden 本质和 style="display: none" 一样，属于纯前端掩耳盗铃行为。真实权限必须由后端决定并返回结果，前端仅做“条件渲染”——比如后端返回 {"can_delete": false}，JS 才决定是否插入删除按钮或绑定点击事件。
用 JavaScript 动态控制元素显示前，先确认权限数据来源
常见错误是把权限硬编码在 JS 里，或从 localStorage 读取角色字符串（如 "role: admin"），这极易被篡改。正确做法是：页面初始化时，由后端模板（如 Django 的 {{ user.permissions }}）或首次 API 响应（如 GET /api/me）返回结构化权限字段，例如：
{
"permissions": ["user:read", "user:edit", "order:delete"],
"menus": ["dashboard", "users", "orders"]
}
之后再用这些数据驱动 DOM 渲染，而不是反过来靠 DOM 状态推断权限。
display 和 visibility 在权限场景下的实际差异
二者都不可用于安全隔离，但影响体验不同：
立即学习“前端免费学习笔记（深入）”；
-
display: none：元素完全脱离文档流，周围元素会重排；适合彻底隐藏无权访问的模块区域 -
visibility: hidden：元素仍占布局空间，仅不可见；适合保留占位、避免页面跳动（如权限切换时的按钮位置） - 两者都可通过 JS 动态设置，但必须基于后端下发的权限标识，而非用户当前 URL 或本地存储值
自定义标签（如 <box>）不是解决方案，而是信号
像 ASP.NET 场景中用 <box id="AddUser"> 标记待控区域，本质是为自动化扫描/权限绑定提供锚点，本身不带任何权限逻辑。真正起作用的是后端系统根据该 id 查数据库中的权限策略，再决定是否向该请求返回对应 HTML 片段或 JSON 数据。如果前端直接解析 <box> 并自行 show/hide，就又退回到客户端可绕过的老路。
最容易被忽略的一点：即使所有按钮、菜单、表单字段都按权限隐藏了，只要后端没对 POST /api/users/delete 这类接口做鉴权校验，攻击者仍能用 curl 或 Postman 直接调用成功。权限控制的成败，永远取决于服务端每次请求的 if !has_permission(req.user, 'user:delete') { return 403 } 这一行判断。
