Sincronizar la configuración con Laravel 13: serializable_classes en caché y sesión en JSON

Hola, bienvenido. En esta lección vamos a añadir a la configuración del proyecto los 2 cambios de seguridad de Laravel 13: 'serializable_classes' => false en config/cache.php y 'serialization' => 'json' en config/session.php. En el esqueleto de Laravel 13 los 2 son valores escritos en el archivo, sin variable de entorno, así que no llegan con composer update, y como vamos a ver, tampoco con config:publish: hay que escribirlos a mano.

Esta lección es más de decidir que de escribir código. Una de las 2 claves cierra las sesiones abiertas de los usuarios en cuanto se despliega el cambio, y la otra puede hacer que lo que se guarda en la caché deje de leerse bien, sin dar ningún error. En la lección 1 dejamos una sesión abierta y algo en la caché al probar el proyecto, y ahora vamos a ver qué les pasa.

La sección "Miscellaneous" de la guía oficial recomienda comparar los archivos del esqueleto laravel/laravel entre las 2 versiones, con la comparación de las ramas 12.x y 13.x en GitHub↗ (se abre en una pestaña nueva). En config/, los 2 cambios que nos afectan son estos:

• config/cache.php gana serializable_classes, con el valor false. Le dice a la caché qué clases puede reconstruir al leer un valor guardado, y con false no reconstruye ninguna.
• config/session.php gana serialization, con el valor json. Cambia cómo se guardan los datos de la sesión: con json_encode() en lugar de serialize().

Las 2 claves evitan lo mismo: que Laravel reconstruya objetos al leer datos guardados. serialize() y unserialize() guardan y reconstruyen objetos de cualquier clase, y al reconstruirlos PHP ejecuta sus métodos mágicos, como __wakeup() o __destruct(). Un ataque de "gadget chain" aprovecha eso: encadena clases que ya existen en vendor/ para que, al deserializar unos datos preparados, se acabe ejecutando código. Laravel plantea estas 2 claves como una defensa para el caso de que se filtre APP_KEY: si alguien consigue que Laravel deserialice datos suyos, con ellas no se crea ningún objeto, así que no se ejecuta ningún método mágico.

¿Y si las claves no están en tu archivo? Entonces Laravel 13 se comporta como Laravel 12: la sesión se guarda con serialize() y la caché reconstruye cualquier clase.

La comparación enseña más diferencias en config/, pero no cambian el comportamiento del proyecto: un store de caché nuevo, storage, que guarda la caché en un disco de config/filesystems.php; un canal de log monthly; la opción days del canal daily, que pasa a llamarse max_files (Laravel 13 sigue leyendo days), y comentarios. Nos vamos a centrar en las 2 claves de seguridad.