如何防止用户修改Electron应用源代码绕过权限校验？

是的，该风险真实存在。默认构建的Electron应用的JS代码通常以明文或者极易反编译的形式存在于打包产物中，用户确实可以通过修改对应的JS文件，将check_if_premium()函数的逻辑改写为固定return true，绕开本地的付费权限校验。

以下是分层级的防护方案，建议搭配使用实现最优效果：

服务端核心防护（从根源规避破解风险） #

这是最有效、最不可绕过的防护手段，所有付费类应用都应该优先落地：

• 不要将高级付费功能的核心逻辑、核心资源打包在客户端安装包内，所有高级功能的计算、敏感数据返回都放在服务端处理，客户端仅承担请求转发和界面渲染的作用。就算用户修改了本地校验逻辑，没有服务端返回的对应数据也无法正常使用付费功能。
• 取消本地一次性校验逻辑，用户每次触发高级功能操作时，都要携带用户token向服务端发起实时权限校验，服务端校验不通过直接拒绝响应该操作。不要将单次check_if_premium()的返回结果长期缓存在本地复用。
• 对高级功能专属的资源、接口做签名校验，只有权限校验通过的请求才能拿到对应的解密密钥、资源访问权限，避免用户直接提取本地缓存的资源离线使用。

客户端侧增强防护（提高篡改成本） #

这类方案无法100%阻止破解，但可以大幅度提高普通用户的篡改门槛，避免破解脚本大范围传播：

• 对所有JS代码做高强度混淆压缩，使用terser、商业JS混淆工具等打乱变量名、函数名，插入冗余执行逻辑，大幅提高用户定位check_if_premium()函数的难度。
• 开启asar打包的同时增加包完整性校验：应用启动时计算asar包的哈希值，和预置的合法哈希值（或每次启动从服务端拉取的最新哈希值）做比对，发现哈希不匹配直接退出应用或禁用所有功能。
• 将核心校验逻辑迁移至Native层实现：用Node.js C++扩展编写核心的权限校验、包完整性校验逻辑，编译为二进制文件引入项目，二进制文件的反编译、篡改难度远高于明文JS代码。
• 增加运行时代码校验逻辑：在业务代码中定期校验check_if_premium()等核心函数的运行时特征（比如函数toString()的哈希值），检测到函数被篡改后直接清空本地用户凭证、退出应用，甚至可以上报服务端对该账号做临时限制。

注意：不要单独依赖客户端侧的防护手段，所有客户端逻辑理论上都可以被破解，必须和服务端核心校验搭配使用才能达到最佳的防护效果。

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