本文介绍在无框架的纯 JavaScript + PHP 开发中，如何有效防御用户通过浏览器开发者工具直接调用 $.post() 篡改并提交虚假分数等关键业务数据，核心方案是将“客户端提交结果”改为“客户端提交行为过程”，由服务端校验逻辑并生成可信结果。
本文介绍在无框架的纯 javascript + php 开发中，如何有效防御用户通过浏览器开发者工具直接调用 `$.post()` 篡改并提交虚假分数等关键业务数据，核心方案是将“客户端提交结果”改为“客户端提交行为过程”，由服务端校验逻辑并生成可信结果。
在前端单机类游戏（如记忆配对游戏）中，仅靠前端计算并提交最终分数（如 score: 11111111）存在根本性安全缺陷：所有客户端数据均可被绕过、篡改或重放。即使你添加了 CSRF Token、请求头校验或前端防调试逻辑，只要接口接收 {"player_name": "Cheater", "score": 999999} 并直接入库，攻击者就能在 DevTools 中一行 $.post(...) 完成作弊——这不是漏洞，而是设计误用。
✅ 正确思路：信任边界必须落在服务端
客户端只负责上报「可验证的行为过程」，服务端负责复现逻辑、校验合法性，并生成唯一可信结果。以记忆游戏为例：
- ❌ 错误做法（当前）：前端计算总分 → 直接提交 score
- ✅ 正确做法：前端记录每一步操作（如翻牌顺序、配对时间、是否错误）→ 提交原始操作日志 → 后端按相同规则重算分数
? 实施示例（轻量级改造）
1. 前端：记录并提交可审计的操作序列
// 在游戏过程中累积操作（例如每次翻牌/配对）
const gameActions = [];
function recordAction(type, data) {
gameActions.push({
type,
data,
timestamp: Date.now()
});
}
// 示例：用户成功配对一对卡片
recordAction('match', { card1: 'cat', card2: 'cat', duration: 1250 });
// 提交时发送完整操作流（而非最终分数）
$("#submitScore").on("click", function() {
const playerName = $('#playerName').val().trim() || "Unknown";
$.post("./backend/save_score.php", {
player_name: playerName,
actions: JSON.stringify(gameActions), // 传输原始行为，非结果
game_id: "memory_v1" // 可选：标识游戏版本，便于后端兼容校验
}, function(response) {
if (response.success) {
fetchHighScores();
$("#submitScore").prop('disabled', true);
} else {
alert("提交失败：" + response.error);
}
});
});2. 后端（save_score.php）：严格校验 + 服务端计分
<?php
header('Content-Type: application/json');
// 简单基础防护（非替代逻辑校验）
if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
die(json_encode(['success' => false, 'error' => 'Method not allowed']));
}
$playerName = filter_var($_POST['player_name'] ?? '', FILTER_SANITIZE_STRING);
$actionsJson = $_POST['actions'] ?? '';
if (empty($playerName) || empty($actionsJson)) {
die(json_encode(['success' => false, 'error' => 'Missing required fields']));
}
$actions = json_decode($actionsJson, true);
if (!is_array($actions) || count($actions) === 0) {
die(json_encode(['success' => false, 'error' => 'Invalid actions format']));
}
// ✅ 关键：服务端重放游戏逻辑，计算可信分数
$totalScore = 0;
$matches = 0;
$errors = 0;
foreach ($actions as $act) {
if ($act['type'] === 'match') {
// 示例规则：匹配正确 +10 分，且需符合游戏逻辑（如不能重复匹配同一对）
$matches++;
$totalScore += 10;
} elseif ($act['type'] === 'mismatch') {
$errors++;
$totalScore = max(0, $totalScore - 2); // 惩罚机制
}
}
// 进阶建议：添加合理性检查（如操作数是否符合关卡设计、时间戳是否异常集中等）
if ($matches < 1 || $matches > 20) { // 假设本局最多10对，即20次匹配
die(json_encode(['success' => false, 'error' => 'Suspicious action count']));
}
// 安全写入数据库（使用预处理防止SQL注入）
$pdo = new PDO('mysql:host=localhost;dbname=game', $user, $pass);
$stmt = $pdo->prepare("INSERT INTO scores (player_name, score, created_at) VALUES (?, ?, NOW())");
$stmt->execute([$playerName, $totalScore]);
echo json_encode(['success' => true, 'score' => $totalScore]);⚠️ 重要注意事项
- 永远不要信任 score、level、time 等结果型字段：它们必须由服务端基于可验证输入生成；
- 操作日志需包含足够上下文：如卡片 ID、操作类型、时间戳、甚至哈希摘要（可选），便于后期审计；
- 加入轻量反自动化策略（非必需但推荐）：例如检测操作间隔是否过短（<100ms 的连续点击极可能为脚本）、要求最小操作步数等；
- CSRF Token 仍建议保留：虽不能阻止此场景作弊，但能防范跨站请求伪造，属于纵深防御一环；
- 前端校验仅用于体验优化：如实时提示“配对成功”，但绝不作为可信依据。
总结来说，防御“控制台提交假分”的本质不是封锁 AJAX 调用，而是重构数据契约——让客户端成为“行为记录仪”，服务端成为“唯一裁判”。这套模式无需框架、不增加复杂度，却能从根本上关闭作弊通道，是轻量级 Web 游戏最务实的安全实践。
