在Laravel中，会话（session）承担着用户认证状态、临时数据等关键信息的存储职责。如果会话数据以明文形式存在于客户端Cookie或服务端文件中，一旦被中间人劫持或服务器被非法访问，用户身份就可能被冒用。因此，合理配置会话加密选项是保障Web应用安全的基础环节。Laravel本身提供了基于APP_KEY的加密机制，但很多项目因为配置不当或驱动切换而意外关闭了保护。
一、Laravel会话加密的基本原理
Laravel的加密功能依赖于APP_KEY环境变量，该密钥在框架安装时通过php artisan key:generate生成，本质是一个随机的32字节字符串，经过base64编码后写入.env文件。当会话驱动配置为cookie时，所有的会话数据会被序列化后使用AES-256-CBC算法加密，再存入客户端的Cookie中；即使攻击者拿到Cookie内容，在没有APP_KEY的情况下也无法解密。
对于file、database、redis等服务端驱动，Laravel默认不会将会话内容加密存储，因为这些数据留在自己的服务器或内网存储里。但cookie驱动必须将encrypt选项设为true，否则会话数据仅经过序列化而未加密，任何人都能用base64解码读出。理解这一差异，是正确配置的第一步。
二、通过配置文件开启会话加密
会话的核心配置文件位于config/session.php。其中有一个名为encrypt的布尔值选项，专门控制是否对Cookie会话进行加密。在Laravel 5.4之后的版本中，该值默认跟随Cookie中间件的加密行为，但若手动修改过，需要检查是否仍为true。
下面是一段典型的配置片段，展示了如何确保加密开启：
<?php
// config/session.php 部分内容
return [
// 驱动类型，使用cookie时加密才直接作用于会话体
'driver' => env('SESSION_DRIVER', 'cookie'),
// 是否加密cookie中的会话数据
'encrypt' => true,
// 会话生命周期（分钟）
'lifetime' => 120,
'files' => storage_path('framework/sessions'),
];
如果项目使用cookie驱动，将encrypt明确设为true后，所有写入的会话都会经过加密。修改配置后，建议清除原有Cookie并重新登录，避免旧明文Cookie被继续携带。同时，.env中的APP_KEY不能丢失或随意变更，否则旧会话全部失效且无法解密。
三、重新生成与妥善保管APP_KEY
APP_KEY是加密和解密的唯一凭据。有些团队将代码提交到仓库时误将.env纳入版本控制，导致密钥泄露；或者直接在多台服务器上使用了不同的APP_KEY，造成会话无法互通。正确做法是每台环境独立生成，并通过安全通道分发。
执行以下命令可重新生成密钥，并自动写入.env：
# 生成新的APP_KEY并写入.env php artisan key:generate # 若使用生产环境配置 php artisan key:generate --env=production
重新生成APP_KEY会使所有已登录用户的会话立即失效，因此在流量低峰期操作较为稳妥。下方的表格列出了不同驱动下APP_KEY的作用范围：
| 会话驱动 | APP_KEY是否用于会话 | 说明 |
|---|---|---|
| cookie | 是 | 会话体经AES加密后存客户端 |
| file | 否 | 明文存于storage，依赖服务器权限 |
| redis | 否 | 数据在内存库，建议网络层加密 |
四、使用Redis驱动时的额外安全考量
当会话驱动切换为redis时，Laravel不再对会话值做应用层加密，数据以明文形式保存在Redis实例中。如果Redis端口直接暴露公网，或同实例被其他不可信业务共用，会话泄露风险依然存在。此时不能只依赖框架默认配置。
一种常见加固方案是在写入会话前自行加密敏感字段，或者启用Redis的TLS传输加密与requirepass鉴权。示例代码如下：
<?php
// 在写入前手动加密敏感数据
use IlluminateSupportFacadesCrypt;
session(['user_token' => Crypt::encryptString($plainToken)]);
// 读取时解密
$token = Crypt::decryptString(session('user_token'));
这样即使Redis被拖库，攻击者也只能看到密文。需要注意的是，Crypt门面同样使用APP_KEY，所以密钥管理策略要和Cookie加密保持一致。对于高安全场景，还可结合网络安全组限制Redis访问来源。
五、常见配置误区与排查方法
不少开发者在调试时为了查看会话内容，临时把encrypt改成false，上线时却忘记还原，导致会话明文外发。另一个误区是认为使用了HTTPS就不需要应用层加密，实际上HTTPS只解决传输层窃听，浏览器端的Cookie本地存储仍可能被恶意脚本读取。
排查时可使用浏览器开发者工具查看Cookie值：若为一串无规律且带IV前缀的密文，说明加密正常；若看到类似a:1:{s:3:"id";i:1;}的序列化字符串，则证明未加密。对应修复方式就是确认config/session.php的encrypt为true且驱动为cookie，或改用服务端驱动并补全访问控制。
安全配置不是一次性的工作，应在每次变更部署流程后复核会话存储与加密状态，确保用户凭证始终处于受保护环境中。
Laravelsession_encryptionencrypted_cookie修改时间：2026-08-06 01:36:30