验证码必须由后端动态生成并存入session或redis,前端仅展示图片且禁止传递原始文本;验证需一次性比对并立即清除,严禁客户端校验。

后端生成验证码并存入 Session 是关键前提
前端展示的验证码图片必须由后端动态生成,且对应文字内容要安全地暂存在服务端(如 session 或 Redis),不能通过 URL 参数、隐藏域或前端 JS 变量传递。否则攻击者可直接读取或重放,验证码形同虚设。
常见错误现象:400 Bad Request 或验证总失败,往往是因为前端提交的 captcha_code 和后端 session['captcha_text'] 不一致——根源常是:Session 未开启、请求跨域导致 session_id 丢失、或验证码图片请求和表单提交不在同一会话上下文(比如图片用 fetch 但没带 credentials: 'include')。
- Flask 示例中务必确认已设置
app.secret_key - Django 需确保
MIDDLEWARE包含'django.contrib.sessions.middleware.SessionMiddleware' - Nginx 反向代理时,检查是否透传了
Cookie头,避免 session_id 被截断
前端需同步刷新验证码图片并绑定校验逻辑
用户点击“换一张”时,仅改 img.src 不够。必须强制浏览器不缓存图片,否则可能反复加载旧验证码。同时,表单提交前应主动校验输入,避免无意义的后端往返。
实操建议:
- 给验证码
<img>的src加时间戳参数:src="/captcha?r=" + Date.now() - 表单
onsubmit中读取用户输入,与空值、长度不足(如少于 4 位)等做初步拦截 - 禁用提交按钮直到用户输入完成,防止重复点击(注意:禁用后需在验证失败时恢复)
示例片段(原生 JS):
document.getElementById('refresh-captcha').onclick = () => {
const img = document.getElementById('captcha-img');
img.src = '/captcha?r=' + Date.now(); // 强制刷新
};
document.getElementById('login-form').onsubmit = (e) => {
const code = document.getElementById('captcha-input').value.trim();
if (!code || code.length
<h3>后端验证必须清除已使用的验证码</h3>
<p>验证码是一次性凭证,验证通过或失败后都应立即从 <code>session</code> 或缓存中删除。否则同一串字符可被重复提交,失去防刷意义。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill4293" title="Doc To HTML"><img
src="https://img.php.cn/upload/skill/000/000/081/178998486916110.jpg" alt="Doc To HTML" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill4293" title="Doc To HTML" class="overflowclass">Doc To HTML</a>
<p class="overflowclass">使用 MinerU 文档处理引擎将 Word 文档(.doc、.docx)转换为保留结构和格式的干净 HTML。</p>
</div>
<a rel="nofollow" href="/xiazai/skill4293" title="Doc To HTML" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
<p>容易踩的坑:</p>
- 只在验证成功时
pop(),失败时漏删 → 攻击者可暴力试错 - 使用 Redis 存储时,误用
GET后不DEL→ 竞态条件下多次消费 - 分布式部署时,Session 存在本地内存,而负载均衡把验证请求打到另一台机器 → 始终查不到
captcha_text
推荐做法:统一用 Redis 的 GETSET 或 GETDEL(Redis 6.2+)原子操作读取并删除;若用 Session,验证逻辑末尾必须显式 session.pop('captcha_text', None)。
不要在客户端生成或校验验证码逻辑
所有涉及“识别图形文字”的判断,包括 OCR 模拟、canvas 像素比对、JS 解密 base64 图片内容等,都不可信。这些逻辑完全暴露在浏览器中,自动化脚本可直接绕过。
真正有效的防线只有两条:
- 图形本身具备一定干扰(扭曲、噪点、粘连),让通用 OCR 工具识别率低于 70%
- 服务端严格比对用户提交字符串与当时生成并存储的原始文本(区分大小写、全半角)
哪怕你用 canvas 在前端画出一模一样的图,只要原始文本没经过服务端参与,整个验证链就断裂了。复杂点在于:验证码图像生成算法、存储时效(建议 ≤5 分钟)、以及失败次数限制(如 5 次错误后锁定 IP 或要求短信辅助)——这些细节比前端交互更值得花时间打磨。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










