PHP中生成CSRF token需用bin2hex(random_bytes(32))存入$_SESSION['csrf_token']，表单隐藏域输出并转义；校验时比对$_POST与$_SESSION值，通过后立即重置token，禁用cookie存储，登录等操作后需同步更新token，校验失败应返回419及JSON错误信息。
PHP里怎么生成和校验CSRF token？
PHP本身不内置CSRF防护，得靠自己管好token的生命周期。核心就两步：生成时存进session，提交时比对。别用时间戳、随机数直接当token——必须绑定当前用户session，否则攻击者能预生成。
- 生成：用
bin2hex(random_bytes(32))生成高强度随机值，存到$_SESSION['csrf_token']里
- 输出：在表单里加隐藏字段
<input type="hidden" name="csrf_token" value="<?php echo htmlspecialchars($_SESSION['csrf_token']); ?>">
- 校验：收到POST后，立刻检查
$_POST['csrf_token']是否等于$_SESSION['csrf_token']，且$_SESSION['csrf_token']不能为空
- 校验通过后，必须立即重置
$_SESSION['csrf_token']（防止重放），比如再生成一个新值
为什么不能把token存在cookie里自动带？
浏览器会自动发送cookie，但CSRF防护的前提是“攻击者无法读取也无法预测token值”。如果把token塞进cookie，又在JS里读出来填表单，等于把防伪码贴在包装盒上——XSS一触发，token就泄露。更糟的是，有些框架（如Laravel）默认用cookie存token但配合SameSite策略，而纯PHP没这种自动机制，手动做极易出错。
- 绝对不要用
$_COOKIE['csrf_token']做校验依据
- 不要通过
document.cookie读token塞进AJAX请求头
- 如果要用AJAX，token必须从HTML模板里取（比如写进
data-token属性），且该HTML本身受session保护
session_regenerate_id()会影响CSRF token吗？
会影响，而且影响很隐蔽。调用session_regenerate_id()会换掉session ID，但不会自动刷新$_SESSION里的数据——旧的$_SESSION['csrf_token']还在，只是session文件被挪了位置。如果在登录成功后调session_regenerate_id(true)，又忘了重新生成token，那用户接下来所有表单都会因token不匹配被拒。
- 登录、权限变更、敏感操作后，只要调了
session_regenerate_id()，就必须紧接着执行$_SESSION['csrf_token'] = bin2hex(random_bytes(32));
- 不要依赖“session启动时自动初始化token”，得在每个需要token的页面逻辑开头显式检查并补全
- 可以封装成函数
ensure_csrf_token()，内部判断!isset($_SESSION['csrf_token'])就生成
POST接口返回419或403，但前端没报错？
这是典型token校验失败却没给明确反馈的情况。PHP里exit或http_response_code(419)之后，如果没输出任何内容，前端fetch可能只收到空响应体，连错误信息都看不到。
- 校验失败时，至少输出
json_encode(['error' => 'Invalid or missing CSRF token'])并设Content-Type: application/json
- 不要用
header('Location: /error')跳转——POST+重定向会丢失原始请求上下文，用户刷新还会重复提交
- 前端AJAX必须检查HTTP状态码，不能只看
response.ok；419应触发token刷新流程（重新GET表单页拿新token）
bin2hex(random_bytes(32))生成高强度随机值，存到$_SESSION['csrf_token']里 <input type="hidden" name="csrf_token" value="<?php echo htmlspecialchars($_SESSION['csrf_token']); ?>"> $_POST['csrf_token']是否等于$_SESSION['csrf_token']，且$_SESSION['csrf_token']不能为空 $_SESSION['csrf_token']（防止重放），比如再生成一个新值 token存在cookie里自动带？
浏览器会自动发送cookie，但CSRF防护的前提是“攻击者无法读取也无法预测token值”。如果把token塞进cookie，又在JS里读出来填表单，等于把防伪码贴在包装盒上——XSS一触发，token就泄露。更糟的是，有些框架（如Laravel）默认用cookie存token但配合SameSite策略，而纯PHP没这种自动机制，手动做极易出错。
- 绝对不要用
$_COOKIE['csrf_token']做校验依据 - 不要通过
document.cookie读token塞进AJAX请求头 - 如果要用AJAX，token必须从HTML模板里取（比如写进
data-token属性），且该HTML本身受session保护
session_regenerate_id()会影响CSRF token吗？
会影响，而且影响很隐蔽。调用session_regenerate_id()会换掉session ID，但不会自动刷新$_SESSION里的数据——旧的$_SESSION['csrf_token']还在，只是session文件被挪了位置。如果在登录成功后调session_regenerate_id(true)，又忘了重新生成token，那用户接下来所有表单都会因token不匹配被拒。
- 登录、权限变更、敏感操作后，只要调了
session_regenerate_id()，就必须紧接着执行$_SESSION['csrf_token'] = bin2hex(random_bytes(32));
- 不要依赖“session启动时自动初始化token”，得在每个需要token的页面逻辑开头显式检查并补全
- 可以封装成函数
ensure_csrf_token()，内部判断!isset($_SESSION['csrf_token'])就生成
POST接口返回419或403，但前端没报错？
这是典型token校验失败却没给明确反馈的情况。PHP里exit或http_response_code(419)之后，如果没输出任何内容，前端fetch可能只收到空响应体，连错误信息都看不到。
- 校验失败时，至少输出
json_encode(['error' => 'Invalid or missing CSRF token'])并设Content-Type: application/json
- 不要用
header('Location: /error')跳转——POST+重定向会丢失原始请求上下文，用户刷新还会重复提交
- 前端AJAX必须检查HTTP状态码，不能只看
response.ok；419应触发token刷新流程（重新GET表单页拿新token）
session_regenerate_id()，就必须紧接着执行$_SESSION['csrf_token'] = bin2hex(random_bytes(32)); ensure_csrf_token()，内部判断!isset($_SESSION['csrf_token'])就生成 exit或http_response_code(419)之后，如果没输出任何内容，前端fetch可能只收到空响应体，连错误信息都看不到。
- 校验失败时，至少输出
json_encode(['error' => 'Invalid or missing CSRF token'])并设Content-Type: application/json - 不要用
header('Location: /error')跳转——POST+重定向会丢失原始请求上下文，用户刷新还会重复提交 - 前端AJAX必须检查HTTP状态码，不能只看
response.ok；419应触发token刷新流程（重新GET表单页拿新token）
CSRF token不是设个变量就完事，它卡在session生命周期、输出时机、前后端协作三个缝里——漏掉任意一环，看着正常，其实形同虚设。
