在 ThinkPHP 的面试中，Cookie 相关的问题几乎是中高级岗位的必考项。很多候选人对 cookie() 助手函数用得滚瓜烂熟，但一旦被追问“Cookie 到底是怎么加密的”“签名和加密有什么区别”“为什么我改了 Cookie 值框架还能检测到”，就开始含糊其辞。这篇文章从面试实战角度出发，把 ThinkPHP 的 Cookie 加密、签名机制和安全配置一次讲透。
一、ThinkPHP Cookie 的默认行为
ThinkPHP 从 5.0 开始，Cookie 的写入和读取都经过了一层安全处理。默认情况下，框架会对 Cookie 值进行加密后再发送给浏览器，读取时自动解密。这意味着你在浏览器开发者工具里看到的 Cookie 值是一串无意义的密文，而不是明文。
相关配置集中在 config/cookie.php 文件中：
return [
// cookie 保存时间
'expire' => 0,
// cookie 有效域名
'domain' => '',
// cookie 路径
'path' => '/',
// cookie 启用安全传输
'secure' => false,
// httponly 设置
'httponly' => true,
// 是否使用 setcookie
'setcookie' => true,
];
注意，这里并没有直接暴露加密和签名的开关。加密相关的配置实际上由 config/app.php 中的几个参数控制。
二、Cookie 加密机制剖析
ThinkPHP 的 Cookie 加密依赖两个核心配置：
// config/app.php
return [
// 应用密钥，参与 Cookie 加密
'app_key' => 'your-app-key-here',
// 默认加密方式
'default_cipher' => 'aes-256-cbc',
];
加密流程（以 ThinkPHP 6 为例）：
- 调用
Cookie::set()写入时，框架将值序列化后，使用app_key和default_cipher指定的算法进行对称加密。 - 加密后的密文经过 base64 编码，再写入 HTTP 响应头。
- 读取时，
Cookie::get()先 base64 解码，再用同样的密钥和算法解密，最后反序列化还原原始值。
面试中常被追问的一个点：app_key 为空会怎样？ 如果 app_key 没有配置，ThinkPHP 会抛出一个异常，提示必须设置 app_key。这是为了防止开发者在不安全的默认状态下运行应用。
另一个高频问题：加密和签名的区别是什么？
- 加密：保证 Cookie 内容的机密性，别人看不到明文。
- 签名：保证 Cookie 内容的完整性，别人改了值能被发现。
ThinkPHP 的 Cookie 默认同时做了这两件事。加密让内容不可读，签名让篡改可检测。如果你只加密不签名，攻击者虽然看不懂内容，但可以随意伪造一段密文，服务端解密后可能得到垃圾数据甚至触发反序列化漏洞。签名则确保了密文必须是由服务端生成的。
三、Cookie 签名与防篡改
ThinkPHP 的签名机制通常和加密绑定在一起。在 Cookie 值写入前，框架会生成一个签名，附加在数据中。读取时先验证签名，签名不匹配则直接丢弃该 Cookie。
在 ThinkPHP 6 中，底层由 think\cookie\Cookie 类配合 think\encryption\Encrypter 完成。Encrypter 的 encrypt() 方法内部会：
- 对序列化后的数据进行加密。
- 生成一个 HMAC 签名，附加到加密数据上。
- 将加密数据和签名一起 base64 编码。
decrypt() 方法则反向操作：先 base64 解码，分离签名和密文，验证 HMAC，通过后才解密。
这意味着，即使攻击者拿到了 app_key（比如通过源码泄露），如果不知道具体的签名算法和序列化方式，伪造 Cookie 仍然有难度。当然，app_key 泄露本身就是严重的安全事故，应该立即更换。
面试加分点：能说出 ThinkPHP 的 Cookie 签名使用的是 HMAC-SHA256，并且签名密钥派生自 app_key，说明你对底层实现有深入了解。
四、安全配置最佳实践
面试官问“如何安全地使用 Cookie”，其实是在考察你的安全意识。以下是必须掌握的配置要点：
1. 设置 httponly
'httponly' => true,
开启后，JavaScript 无法通过 document.cookie 读取 Cookie，能有效缓解 XSS 攻击导致的 Cookie 窃取。这是默认开启的，但有些开发者为了前端方便会关掉，这是非常危险的做法。
2. 设置 secure
'secure' => true,
仅在 HTTPS 连接下发送 Cookie。如果你的站点全站 HTTPS，务必开启。开发环境没有 HTTPS 时可以设为 false，但生产环境必须为 true。
3. 设置 SameSite
ThinkPHP 的 Cookie 配置中可能没有直接暴露 SameSite 选项，但你可以通过原生 setcookie() 的 options 数组或响应头来设置。SameSite 能有效防御 CSRF 攻击：
SameSite=Lax：默认值，允许顶级导航携带 Cookie。SameSite=Strict：最严格，任何跨站请求都不携带 Cookie。SameSite=None：必须配合Secure使用。
4. 定期更换 app_key
app_key 是 Cookie 安全的根基。一旦怀疑泄露，立即更换。更换后所有已签发的 Cookie 都会失效，用户需要重新登录，但这正是安全性的体现。
5. 敏感信息不要放 Cookie
即使有加密，Cookie 也不是保险箱。用户的密码、支付信息等绝对不要写入 Cookie。Session ID 可以放，但也要配合上述安全配置。
五、常见面试题速答
Q：ThinkPHP 的 Cookie 加密用的什么算法？
A：默认 aes-256-cbc，可通过 default_cipher 配置修改，密钥来自 app_key。
Q：为什么我手动改了 Cookie 值，框架读取后返回 null？
A：因为签名验证不通过。你修改后的值无法通过 HMAC 校验，框架直接丢弃了该 Cookie。
Q：app_key 为空会怎样？
A：ThinkPHP 会抛出异常，阻止应用在不安全状态下运行。
Q：Cookie 加密和 Session 加密是一回事吗？
A：不是。Session 数据默认存在服务端文件或缓存中，客户端只保存 Session ID。Cookie 加密保护的是客户端存储的数据本身。两者使用的加密组件可能相同，但保护的对象不同。
Q：如何关闭 Cookie 加密？
A：不推荐关闭。如果确实需要，可以在写入时手动设置，但会丧失框架提供的安全保障。面试中遇到这个问题，应该先反问“为什么要关闭”，再说明关闭的风险。
六、总结
ThinkPHP 的 Cookie 机制围绕 app_key 构建了一套加密加签名的双重防护体系。加密保证机密性，签名保证完整性，配合 httponly、secure、SameSite 等配置，能抵御大部分常见的 Web 攻击。面试中回答这类问题，不要只背配置项，要能说清楚“为什么需要这个配置”“不加会有什么后果”，这才是区分初级和中级开发者的关键。
建议你在本地环境中实际修改 app_key 和 default_cipher，观察 Cookie 值的变化，动手验证一遍，比死记硬背有效得多。
未经允许不得转载：任鹏个人博客 » ThinkPHP 面试精讲：Cookie 加密、签名与安全配置
