如何防止用户修改JS脚本地址、非法调用PHP Laravel后端接口

一、关于脚本篡改校验的实现 #

纯前端侧没有100%阻止用户修改JS脚本地址/篡改脚本内容的方法，因为所有前端代码在用户侧都是可读写的，但可以通过多层校验大幅提高篡改成本，常见可行方案：

• 开启子资源完整性校验（SRI）：你发布脚本的时候生成对应的SHA-256哈希值，提供给用户添加到script标签的integrity属性中，浏览器会自动校验下载的脚本内容和哈希是否匹配，不匹配则直接拒绝执行，从浏览器层面避免脚本被篡改后运行
• 给你提供给用户的脚本地址加带时效的签名：用户引入脚本的时候需要用你分配给他们的唯一域名标识+密钥生成签名参数，你在返回脚本资源的时候校验签名，非法域名/过期签名直接返回403
• 脚本内部加入运行时校验逻辑：脚本加载后自动读取当前script标签的src属性，和内置的合法域名白名单做比对，如果不符合直接停止运行，同时上报异常请求到你的服务端。这个校验逻辑要做混淆处理，避免被恶意用户直接定位删除，建议用JS混淆工具把核心校验代码做AST混淆、加死代码、控制流平坦化处理，提高逆向成本

二、接口防恶意调用的通用方案（适配Laravel后端） #

1. 轻量基础防护：CORS + 签名校验组合 #

• 首先配置Laravel的CORS中间件，只允许你授权的域名跨域请求接口，未授权的域名浏览器会直接拦截请求，不过这个只能防浏览器端的普通调用，挡不住cURL/自定义程序请求
• 加入请求签名校验机制：
  1. 给每个授权的用户分配唯一的app_key和app_secret，app_secret只允许在用户的服务端存储，绝对不能暴露在前端
  2. 用户的服务端需要在渲染页面的时候，生成带时效的请求令牌：将当前时间戳、用户域名、随机字符串用app_secret做哈希签名，把时间戳、随机串、签名、app_key一起输出到前端页面
  3. 你的JS API发起请求的时候，自动携带这些参数到你的服务端
  4. Laravel侧自定义中间件做校验，核心逻辑参考示例：

<?php
namespace App\Http\Middleware;
use Closure;
use App\Models\AuthorizedApp;

class VerifyApiSignature
{
    public function handle($request, Closure $next)
    {
        $reqParams = $request->only(['app_key', 'timestamp', 'nonce', 'sign']);
        // 校验参数是否齐全
        if (count(array_filter($reqParams)) != 4) {
            return response()->json(['message' => '非法请求'], 403);
        }
        // 校验时间戳有效期，5分钟内
        if (abs(time() - $reqParams['timestamp']) > 300) {
            return response()->json(['message' => '请求已过期'], 403);
        }
        // 取出对应app的密钥和绑定域名
        $app = AuthorizedApp::where('app_key', $reqParams['app_key'])->first();
        if (!$app) return response()->json(['message' => '无效的app_key'], 403);
        // 校验域名
        if ($request->header('Origin') != $app->bind_domain) {
            return response()->json(['message' => '域名未授权'], 403);
        }
        // 生成签名比对
        $checkSign = hash('sha256', $reqParams['app_key'] . $reqParams['timestamp'] . $reqParams['nonce'] . $app->app_secret);
        if ($checkSign != $reqParams['sign']) {
            return response()->json(['message' => '签名校验失败'], 403);
        }
        return $next($request);
    }
}

2. 高强度防爬补充方案 #

如果对接口安全要求极高，可以叠加以下措施：

• 开启请求频率限制，直接使用Laravel自带的throttle中间件，每个app_key每分钟允许的请求次数根据业务场景设置，超过阈值直接返回429
• 加入动态令牌机制：每次合法请求返回新的单次有效令牌，下一次请求必须携带上一次返回的令牌，大幅提高批量模拟请求的成本
• 敏感数据做前端渲染混淆，不要直接返回明文JSON，JS脚本内置解密逻辑，拿到加密数据后解密再渲染，即使接口被爬拿到的也是密文

三、补充说明 #

HTTP_REFERER确实可以被篡改，只能作为辅助校验项，不要作为唯一校验依据；所有前端侧的校验都只能提高破解成本，核心校验逻辑必须落在服务端实现。

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