Symfony默认启用CSRF防护，但仅对标准表单生效；API、AJAX等需手动集成，否则因未触发防护机制而报InvalidCsrfTokenException。
CSRF 令牌为什么在 API 请求里失效
很多人发现 form_login 正常校验，但用 fetch 或 axios 调 /api/login 却提示 InvalidCsrfTokenException —— 实际上这不是“失效”，而是根本没启用。Symfony 的 CSRF 保护只绑定在 FormType 渲染的 HTML 表单上，security.yaml 中的 form_login 配置本身不自动为 JSON 接口加令牌。
- CSRF 字段（默认名
_token）由FormTypeCsrfExtension注入，仅当使用$this->createForm()+->createView()时才生成 - 纯 API 场景需改用 JWT/OAuth2，或手动在请求头中传
X-CSRF-Token并在控制器里调用$csrfTokenManager->isTokenValid() - 若坚持用表单式 API，可在
MyApiType中显式开启：'csrf_protection' => true，但必须配套提供$csrfTokenManager->getToken('my_api_token')值
SecurityBundle 的防火墙配置陷阱
security.yaml 里的 firewalls 不是“开关”，而是匹配规则驱动的拦截器链。写错 pattern 或漏掉 stateless: true，会导致认证逻辑静默跳过或反复重定向。
-
pattern: ^/api匹配路径前缀，但^/api/（末尾斜杠）会漏掉/api根路径 —— 必须写成^/api或^/api/.* - JWT 认证必须设
stateless: true，否则 Symfony 会尝试写 session，导致无 Cookie 环境（如移动端、CLI）下InvalidCsrfTokenException报错 - 多个防火墙共存时，
main和api不能共享同一provider，除非该 provider 同时支持UserInterface和TokenInterface实现
微服务场景下 Voter 权限判断失效
Voter 只在当前服务进程内运行，无法跨服务校验权限。比如订单服务调用用户服务的 /user/{id} 接口时，PostEditVoter 在订单服务里毫无意义 —— 它根本看不到用户服务的实体上下文。
- ABAC/RBAC 规则必须下沉到被调用方（即用户服务），由其自身
Voter或策略服务执行 - 避免在调用方做
$this->isGranted('USER_DELETE', $user)，这只会查本地缓存或抛AuthenticationCredentialsNotFoundException - 推荐用 OAuth2 scope 控制接口粒度（如
scope: user:read），而非依赖 Symfony 的isGranted()跨服务调用
虚拟线程（PHP 8.3+）下静态状态引发的安全污染
Symfony 7 运行在虚拟线程模式时，static 属性不再线程安全。一个请求修改了 SomeService::$cache，另一个并发请求可能读到脏数据，且不会报错 —— 日志里只显示偶发的权限错误或数据错乱。
- 检查所有自定义服务：把
private static $counter改成private int $counter，依赖容器每次新建实例 -
$_SESSION、$_SERVER等超全局变量已被 Symfony 封装为上下文感知对象，直接访问会返回空或默认值 - 若必须共享状态，用
CacheInterface+ Redis，禁用 APCu 或文件缓存（它们在虚拟线程下未做隔离）
csrf_protection: true 就万事大吉，结果 API 接口裸奔；以为写了 access_control 就自动生效，却忘了防火墙 pattern 没覆盖到新路由。安全机制从不自动蔓延，它只在你明确画出边界的地方起作用。 
