ping属性需与合法href共存才生效，Chrome默认启用但可手动禁用，Firefox默认彻底禁用且不可开启，Safari从未支持；其请求绕过CORS、Cookie策略及前端监控，存在隐私泄露与DDoS风险，须后端严格校验与限速。
ping 属性确实能实现无 JS、无阻塞的点击跟踪，但它不是“开箱即用”的安全埋点方案——浏览器发请求不经过 CORS、不校验意图、同源时自动带 Cookie，稍不注意就变成隐私泄露口或 DDoS 中转站。
ping 属性必须和 href 一起用，否则无效
单独写 <a ping="https://log.example.com">点我</a> 不会触发任何请求。浏览器强制要求 ping 必须与 href 共存，且 href 值需为合法 URL（不能是 javascript:void(0) 或空字符串）。
- ✅ 正确：
<a href="/product/123" ping="https://log.example.com">查看详情</a> - ❌ 无效：
<a ping="https://log.example.com">查看详情</a>（缺href） - ❌ 无效：
<a href="#" ping="https://log.example.com">查看详情</a>（#不是可跳转 URL，Chrome/Firefox 均不触发 ping） - ⚠️ 注意：Safari 完全不支持
ping，无需检测特性，直接按 UA 判断更可靠（但 UA 可伪造，后端不能依赖）
后端接收 ping 请求必须严格校验头和内容类型
浏览器发来的 ping 请求是 POST，Content-Type: text/ping（不是 text/pingback，后者属于 WordPress 旧协议），但攻击者可以伪造任意头和类型。不校验就等于开放 SSRF 和日志注入入口。
- 必须拒绝非
text/ping的Content-Type，如application/ping、text/plain - 必须校验
PING-FROM头：需为合法 HTTP(S) URL，且不能含内网地址（如http://127.0.0.1、http://192.168.1.100） - 必须限速：单 IP 每分钟最多 3 次，超限返回
429 Too Many Requests，且响应体为空（避免被用作探测通道） - 不要解析请求体——标准行为下它通常为空；若收到非空 body，应视为异常并记录告警
同源 ping 会静默携带 Cookie，等价于一次未授权的会话调用
如果 ping 指向同域 endpoint（如 ping="/api/click"），浏览器会在请求中自动带上当前域的所有 Cookie，包括登录态 token。这意味着：用户没主动发起 API 调用，却已触发了一次带身份的后台请求。
立即学习“前端免费学习笔记（深入）”；
- 风险点：内网系统若嵌了第三方广告 banner，而该 banner 含
ping指向同域日志接口，PING-FROM会暴露完整内网路径（如https://intranet.company.local/admin?user=alice） - 缓解方式：日志 endpoint 必须设为跨域独立子域（如
log.yourapp.com），并确保其不接受 Cookie；或在后端显式忽略Cookie头 - 别指望
SameSite=Lax或Secure标志——ping请求不受这些策略约束
它绕过 referrerpolicy，也绕过前端所有监控手段
ping 请求不走 fetch 或 XMLHttpRequest，因此不会触发 beforeunload、sendBeacon、CSP connect-src 检查，也不会出现在 DevTools 的 Network 面板（除非手动开启“All”过滤并勾选 “Ping” 类型）。
-
referrerpolicy="no-referrer"对它完全无效：PING-FROM头仍会携带完整来源 URL - 前端无法监听、拦截、重写或取消该请求——它是浏览器原生行为，JS 无权干预
- WAF 和防火墙很难识别：流量无响应体、无重试、无错误回调，日志里只有一行
POST /api/ping HTTP/1.1 200 -，和正常业务日志混在一起 - 真实攻击案例中，QQ 浏览器曾因默认启用且缺乏服务端防护，被用于将数千万普通用户变成 DDoS “肉鸡”
真正麻烦的不是怎么发 ping，而是你根本不知道它什么时候被谁、以什么形式、带着哪些敏感上下文发出去了——后端防护必须前置，不能靠前端“规范使用”来兜底。
