本文介绍如何在 laravel 中安全地动态应用用户自定义的验证规则，通过正则预校验防止恶意篡改，确保仅允许白名单内的合法规则被执行，避免因非法规则导致的异常或安全风险。
在支持用户自定义字段（如商品扩展属性）的 Laravel 应用中，常需将前端提交的验证规则（如 after:today、min:5）持久化至数据库，并在表单提交时动态加载并应用。但若直接信任用户输入的规则字符串，攻击者可能注入非法或危险规则（如 exists:users,password 或自定义闭包规则），导致 SQL 注入、信息泄露或运行时崩溃。
因此，必须在规则应用前进行严格白名单校验。推荐采用「正则预匹配 + 规则标准化」双保险策略：
✅ 白名单正则校验（核心防护）
以下正则表达式覆盖 Laravel 10+ 常用内置规则及其参数格式，支持带冒号的参数化规则（如 between:1,100）、可选修饰符（如 distinct:strict）及日期字面量（如 after:2025-01-01）：
$rulePattern = '/^
(accepted|nullable|active_url|alpha(_dash)?|array|boolean|date|declined|distinct(:(strict|ignore_case))?
|email(:(((rfc|dns|strict|spoof|filter),){1,4})?(rfc|dns|strict|spoof|filter))?
|integer|ip(v[46])?|mac_address|json|required|string|url
|size:[0-9]{1,9}
|(max|min|multiple_of):(-?[0-9]{1,9})
|(ends|starts)_with:([A-Za-z0-9_,]+[A-Za-z0-9])
|digits_between:[0-9]{1,2},[0-9]{1,2}
|digits:(-?[0-9]{1,2})
|between:(-?[0-9]{1,9}),(-?[0-9]{1,9})
|(after|before)(_or_equal)?:((today)|[0-9]{4}-(0?[1-9]|1[0-2])-(0?[1-9]|[12][0-9]|3[01]))
$/x';
// 校验单条规则
$isValid = (bool) preg_match($rulePattern, trim($userRule));
// 校验多条规则（逗号分隔）
$rules = array_map('trim', explode(',', $userRulesString));
foreach ($rules as $rule) {
if (!preg_match($rulePattern, $rule)) {
throw new InvalidArgumentException("Invalid validation rule: {$rule}");
}
}⚠️ 注意事项： 正则使用 /x 修饰符启用注释与空白忽略，提升可维护性； 日期格式校验仅支持 YYYY-MM-DD 和 today，不支持 now、+1 day 等动态表达式，避免执行风险； email: 后缀参数严格限定为 Laravel 官方支持的 rfc/dns/strict/spoof/filter，禁用未定义修饰符； 所有数字参数限制位数（如 9 位整数），防超长字符串拒绝服务（ReDoS）。
✅ 补充防护建议
- 服务端规则映射：将用户选择的规则 ID（如 RULE_AFTER_TODAY）映射为固定规则字符串，避免直接解析原始输入；
- 验证器实例化前拦截：在 Validator::make() 前统一校验 $rules 数组，失败则立即返回 422 错误；
- 日志审计：记录所有被拒绝的非法规则尝试，便于安全分析；
- 定期同步白名单：Laravel 版本升级后，及时更新正则以兼容新规则（如 Laravel 11 新增的 prohibited_if）。
通过该方案，你既能灵活支持用户驱动的验证配置，又能从根本上杜绝规则注入风险，兼顾扩展性与安全性。
