17370845950

前端验证码校验只能防用户手误和简单脚本误触，无法防爬虫、自动化工具或绕过前端的攻击；因JS逻辑完全暴露，攻击者可直接调用接口跳过校验。

前端验证码校验能防什么？不能防什么？

前端实现的 验证码校验 本质只是“体验层过滤”，它能拦住用户手误、重复提交或简单脚本的误触，但**完全无法阻止爬虫、自动化工具或绕过前端逻辑的攻击**。因为所有 JS 代码、校验逻辑、甚至验证码图片的 URL 都可被直接查看和复现。攻击者只要调用你页面里暴露的 fetch 或 axios 请求，跳过输入框和 JS 校验，就能直连后端接口。

为什么不能只靠 JavaScript 做验证码验证？

关键原因在于执行环境不可信：用户可以禁用 JS、修改内存中的变量、重放请求、或用 Puppeteer 等工具模拟完整浏览器行为。常见错误包括：

• 把验证码答案（如 captchaText）明文存在 data- 属性或全局变量里，被轻易读取
• 仅用 if (inputValue === storedCode) 判断，而 storedCode 是前端生成或从接口同步返回的
• 校验通过后不刷新验证码，导致同*被反复使用
• 未对后端接口做二次校验，或后端校验逻辑与前端一致（比如也比对明文字符串）

前端该做什么？怎么配合后端才安全？

前端的合理角色是「增强体验 + 增加攻击成本」，必须和后端形成闭环。实操要点：

• 验证码图片由后端返回，且响应头带 Cache-Control: no-store，避免被缓存复用
• 每次获取验证码时，后端应生成唯一 captchaId 并返回，前端将其作为隐藏字段随表单提交
• 用户提交时，前端只做基础格式检查（如非空、长度4–6位），**不比对内容**；真正校验交由后端用 captchaId 查 Redis 或内存缓存中的真实值
• 后端校验通过后立即失效该 captchaId，防止重放
• 前端提交失败（如后端返回 { code: 400, msg: "验证码错误" }）时，自动刷新验证码并清空输入框

fetch('/api/login', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    username: 'test',
    password: '123',
    captcha: document.getElementById('captcha-input').value,
    captchaId: document.getElementById('captcha-id').value // 来自上一步接口
  })
})
.then(r => r.json())
.then(data => {
  if (data.code === 400 && data.msg.includes('验证码')) {
    refreshCaptcha(); // 调用刷新函数
  }
});

一个典型不安全的 JS 验证写法长什么样？

下面这段代码看似“做了验证”，实则毫无安全价值：

let realCode = 'ABCD'; // ❌ 千万别这么干！硬编码或从接口明文返回
function verify() {
  const input = document.getElementById('captcha-input').value;
  if (input.toUpperCase() === realCode) {
    submitForm(); // 直接发请求
  } else {
    alert('验证码错误');
  }
}

真实项目中，realCode 可能来自 fetch('/captcha').then(r => r.text())，但只要没加密、没绑定 session、没限时，就等于把钥匙挂在门把手上。真正的安全边界永远在服务端——前端只是门帘，不是门锁。