https是mercure安全的前提，因为mercure协议本身不内置加密，完全依赖底层https传输层加密保护jwt令牌和事件数据，防止中间人明文窃取；若未启用https或客户端忽略证书警告，所有推送内容将裸露于arp欺骗、wifi劫持等攻击之下。
Mercure推送内容在传输层是加密的，中间人无法直接解密明文内容——但前提是正确配置HTTPS且客户端不忽略证书警告。
为什么HTTPS是Mercure安全的前提
Mercure协议本身不内置加密，它依赖底层传输协议。FrankenPHP内置的Mercure Hub默认通过HTTP/2或HTTP/3承载，而Caddy会自动为localhost签发本地证书、对外部域名强制要求有效TLS证书。如果服务端未启用HTTPS（比如用HTTP暴露Mercure的/.well-known/mercure端点），所有推送消息（包括JWT令牌、事件数据）都将明文传输，ARP欺骗或WiFi热点攻击者可直接抓包读取。
- FrankenPHP镜像中Caddy默认监听
https://并重定向HTTP请求，但若手动注释了redir或禁用TLS，风险立即出现 - 前端订阅Mercure时若用
new EventSource("http://...")而非https://，浏览器会直接拒绝连接（现代浏览器策略），但部分旧环境或调试代理可能绕过 - Mercure JWT中的
publish和subscribe权限由服务端校验，但token本身若被截获，攻击者可在有效期内冒充合法发布者（需配合HTTPS失效才易得手）
Cookie与JWT混合鉴权时的典型泄露点
FrankenPHP的Mercure集成常复用PHP会话机制，例如通过$_SESSION生成JWT或校验订阅权限。此时若session.cookie_secure未设为On，PHPSESSID Cookie可能通过HTTP明文发送，导致会话劫持——攻击者拿到会话ID后，可伪造请求向Mercure Hub订阅任意主题。
- 检查php.ini中是否设置了
session.cookie_secure = 1和session.cookie_httponly = 1 - 避免在前端JS中读取
document.cookie拼接Mercure URL，这会把敏感凭证暴露给XSS脚本 - 使用
Set-Cookie响应头时，确保包含Secure; HttpOnly; SameSite=Strict三属性
Caddy配置中容易被忽略的Mercure安全开关
FrankenPHP镜像自带的Caddyfile虽启用了Mercure模块，但默认未限制主题白名单或JWT签名密钥强度。攻击者若能控制客户端发起恶意订阅（如topic=https://example.com/*），可能收到非预期事件——这不是中间人问题，而是服务端鉴权缺失。
- 在
Caddyfile.d/mercure.caddyfile中显式配置subscribe_allowed和publish_allowed规则，例如subscribe_allowed ["https://api.example.com/users/{id}"] - 通过环境变量
MERCURE_PUBLISH_ALLOWED注入白名单，避免硬编码在配置里 - 使用
frankenphp mercure generate-key生成强密钥，而非依赖默认的secret字符串（该值若泄露，JWT可被任意伪造）
真正危险的不是Mercure协议本身，而是HTTPS配置松动、会话Cookie裸奔、以及Caddy中Mercure模块的默认宽松策略——这三个环节只要一个没卡死，中间人就可能借道切入。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
