如何防止用户搜索历史被篡改？

核心区分两件事：

1. 前端 localStorage 本地搜索历史：用户本机可以手动改浏览器存储，无法做到绝对不可篡改，只能做到「篡改可检测」；
2. 后端数据库保存的搜索记录（登录用户历史、全站搜索日志）：可以做到强防篡改，不允许任意修改。

一、前端 localStorage（未登录访客个人搜索历史）防篡改

重点：浏览器 localStorage 本身对当前域名 JS 可读可写；用户打开开发者工具直接修改 JSON，这是浏览器原生机制，无法阻止用户手动修改自己本机的数据，只能校验，发现篡改后丢弃数据。

1. HMAC/SHA256 校验签名（推荐轻量方案）

存储结构：{data:搜索历史数组, sign:哈希签名}

1. 写入：把关键词数组 + 时间戳拼接，用密钥计算 HMAC-SHA256，把签名一起存入 localStorage
2. 读取：取出 data，使用同一个密钥重新计算签名，和存储的 sign 对比
   • ✅ 匹配：正常渲染搜索历史
   • ❌ 不匹配：判定数据被篡改，直接清空本条本地历史，降级展示全站热门词

密钥放内存，不要明文存在 localStorage 里；密钥仅前端 JS 运行时持有。

2. 基础数据合法性校验（必须做）

读取本地历史后，先做规则校验，拦截恶意篡改后的脏数据：

• 条数校验：不能超过上限（例如最多 8 条）
• 字符校验：关键词长度 2~50 字符；过滤脚本标签、SQL 注入 payload
• 时间戳校验：过期记录直接丢弃；时间不能是未来时间
• 类型校验：必须是数组，不能是字符串 / 对象等异常结构

3. 减少 XSS 导致的被动篡改（攻击者远程篡改本地记录）

• 全站 CSP 内容安全策略，禁止非受信脚本，阻断 XSS；XSS 是远程篡改 localStorage 最主要入口
• 第三方广告、统计脚本隔离，禁止读取你的 localStorage
• 输入输出 HTML 转义，防止存储型 XSS 写入恶意代码

提醒：本地存储只用于前端下拉推荐，不能作为可信数据源，重要业务逻辑不能依赖本地搜索历史

4. 简易版取舍（中小企业官网）

如果开发成本有限，不做 HMAC 签名，仅做数据格式校验。就算用户手动篡改本地历史，只是下拉推荐词异常，不会污染后端数据，业务风险很低。

二、后端数据库存储搜索记录（登录用户历史 + 全站匿名日志）【重点，可做到强防篡改】

后端存储是可信数据，禁止前端直接提交、修改、删除历史记录，所有写入动作由后端服务自主生成。

1. 写入权限控制：前端只能触发，不能直接写记录

❌ 错误：前端把完整搜索历史提交给后端保存（前端可以随意伪造记录） ✅ 正确流程：

1. 用户提交搜索词给后端搜索接口；
2. 后端服务在收到合法搜索请求后，由后端生成搜索记录写入数据库；
3. 前端无权直接新增 / 修改 / 删除后端保存的搜索历史；
4. 删除操作：用户点击清除历史，后端接口校验身份后，由后端执行删除。

一句话：搜索记录的写入主体是后端，不是前端提交的历史数组，杜绝前端伪造篡改。

2. 数据库层防篡改方案

1. 日志表使用追加写入（Append Only） 全站匿名搜索日志，只新增，禁止 UPDATE 更新旧记录，数据库层面关闭修改权限，只能 insert。只能新增记录，不能修改过往搜索日志，适合统计分析用的搜索日志。

如果业务需要修正脏数据，单独建归档审计表，保留原始记录不动。

2. 记录附加哈希校验字段 每一条后端搜索记录入库时，把user_id、search_word、time、has_result拼接计算 SHA256，存入本条记录的 hash 字段。定期校验：读取记录重新算哈希，不一致代表记录被修改，触发告警。
3. 独立数据表、最小数据库账号权限

• 搜索历史表、审计表独立，和会员主表隔离；
• 业务数据库账号只有 INSERT、SELECT，禁止 UPDATE/DELETE 权限（日志表）；
• DBA / 管理员账号单独管控，所有修改操作留下审计日志。

4. 审计追踪（谁改了、何时改） 任何对登录用户搜索历史的修改 / 删除操作，单独写入不可篡改审计日志，记录操作人 IP、账号、时间、操作类型；审计日志同样 append-only，不可修改。

3. 传输过程防篡改（HTTPS + 接口验签）

1. 全站 HTTPS，防止传输中途抓包篡改请求参数；
2. 搜索接口增加请求签名（HMAC）：前端请求参数 + 时间戳生成签名，后端校验；防止中间人篡改搜索词；
3. 接口限流、防重放：增加 nonce 随机数 + 请求时效（例如 1 分钟过期），拦截重放攻击伪造搜索记录。

三、业务兜底校验：前后端双校验，不信任单一来源

1. 前端展示下拉推荐：优先读取 localStorage 历史（带签名校验）；一旦校验失败，直接抛弃本地数据，只展示全站热门词，不把篡改后的脏词提交后端。
2. 后端统计分析：只信任后端自己写入的搜索日志，完全不使用前端上传的搜索历史数组做数据分析。
3. 异常监控：后端识别短时间大量异常关键词、超长 payload、异常会话，标记可疑数据并告警。

四、两种场景的边界说明（非常关键）

1. 未登录访客 localStorage 历史 用户本机开发者工具可以手动修改，无法绝对阻止篡改，防护目标：

• 阻止 XSS 攻击远程篡改；
• 篡改发生后可以识别，自动丢弃脏数据，不污染业务。

2. 登录账号后端保存的搜索历史、全站统计日志 可以做到强防篡改：不允许修改已有记录，所有变更留审计日志，任何改动都会被发现。

五、上线自查清单

• 前端本地搜索历史增加 HMAC 签名 + 数据合法性校验
• CSP 策略部署，减少 XSS 风险
• 后端搜索记录由后端自动写入，前端不能提交完整历史数组
• 全站搜索日志表设置 Append Only，禁止 UPDATE
• 数据库账号最小权限，日志表禁止更新
• 接口 HTTPS，请求加签名、防重放
• 审计日志独立，记录所有后台数据操作
• 校验失败处理逻辑：自动清空脏数据，降级展示热门词