如何防止用户通过Chrome开发者工具修改/删除按钮禁用属性

嘿，这个问题可是前端权限控制里的经典“坑”——前端的disabled状态从来都不是安全防护，只是给普通用户的友好提示罢了。要彻底堵住开发者工具篡改DOM的漏洞，得从前后端一起设防，给你几个落地性强的方案：

1. 核心防线：后端权限校验（必须做！） #

这是最根本的解决方案，因为前端的任何操作最终都要请求后端接口。不管用户怎么篡改前端DOM，只要后端在接口层面严格校验权限，就能直接把非法请求拦下来：

• 每个涉及权限的接口，在处理请求前都要先验证当前用户的权限。比如用户点击按钮触发的删除接口，后端要先查用户是否有删除权限，没有就直接返回403错误，完全不执行后续逻辑。
• 伪代码示例（以Python Flask为例）：

@app.post("/api/delete-resource")
def delete_resource(current_user):
    # 从请求上下文获取当前登录用户
    if not current_user.permissions.get("delete_resource"):
        return {"error": "无操作权限"}, 403
    # 执行正常的删除逻辑
    return {"success": True}

2. 前端加固：增加篡改成本 #

虽然后端是核心，但前端也可以做一些优化，让用户篡改DOM后也无法轻易触发操作：

• 点击事件中加入权限校验：不要只依赖disabled属性，在按钮的点击回调里先检查用户权限。就算用户删掉了disabled，点击时也会被拦截：

const handleActionClick = () => {
    // 从后端获取的权限信息（存在前端状态中，仅初始化时加载）
    const hasPermission = window.userPermissions.includes("target_action");
    if (!hasPermission) {
        alert("你没有执行该操作的权限");
        return;
    }
    // 发起请求或执行操作
    fetch("/api/action", { method: "POST" });
};

• 用CSS模拟禁用状态，替代原生disabled：如果不想用原生disabled属性，可以通过CSS把按钮样式改成禁用状态（比如背景灰、光标禁止），同时在点击事件里拦截。这样DOM里没有明确的disabled属性，用户想篡改也找不到明确的修改点，增加操作成本。
• 前端状态锁死权限信息：把用户权限存在前端状态管理工具（比如Pinia、Redux）中，并且设置为只读，只在页面初始化时从后端拉取。按钮的可点击状态完全依赖这个状态，就算用户改了DOM，状态里的权限依然不变，点击校验还是会生效。

3. 额外补充：敏感操作加二次验证 #

对于特别重要的操作（比如删除数据、修改配置），除了前后端权限校验，还可以在前端加入二次验证，比如要求用户输入登录密码、验证码，进一步提高操作门槛，就算用户篡改了按钮，也过不了这一关。

内容的提问来源于stack exchange，提问作者booom