Для чого Laravel використовує APP_KEY і як його безпечно змінити?

APP_KEY - головний секрет застосунку. Ним Laravel шифрує й підписує дані, що залишають сервер чи зберігаються:

• cookie: сесійна cookie й інші cookie, які шифрує middleware EncryptCookies;
• сесії (якщо SESSION_ENCRYPT=true);
• підписані URL (URL::signedRoute, посилання підтвердження email);
• дані, зашифровані через Crypt та касти encrypted у моделях;
• сторонні механізми, що на нього спираються (наприклад, підпис знімків стану Livewire).

Генерується командою php artisan key:generate (AES-256, 32 байти, у .env як base64:...).

Чому ключ не можна просто замінити: після зміни все, що зашифровано старим ключем, перестає розшифровуватися:

• користувачі розлогінюються (cookie недійсні);
• посилання з листів (підтвердження, скидання) перестають працювати;
• дані в базі з кастом encrypted стають нечитабельними - це найнебезпечніше.

Плавна ротація: старі ключі перелічуються в APP_PREVIOUS_KEYS:

APP_KEY=base64:новий...
APP_PREVIOUS_KEYS=base64:старий...

Laravel шифрує лише новим ключем, а розшифровує - пробуючи поточний і попередні. Користувачі не розлогінюються, старі посилання діють.

Повна ротація (наприклад, після витоку ключа):

1. новий ключ у APP_KEY, старий - у APP_PREVIOUS_KEYS;
2. перешифрувати дані в базі новим ключем (команда, що читає й зберігає кожне зашифроване поле);
3. через час, достатній для завершення сесій і закінчення терміну посилань, прибрати старий ключ з APP_PREVIOUS_KEYS.

Правила зберігання:

• у .env чи менеджері секретів, ніколи в репозиторії;
• різні ключі для середовищ (локальне, тестове, продакшен) - інакше cookie з тестового стенда підходять до продакшену;
• однаковий ключ на всіх серверах одного середовища - інакше сесії «ламаються» при переході між серверами за балансувальником;
• при підозрі на витік - ротація і перешифрування.

Не плутати з хешуванням паролів: паролі хешуються (bcrypt/argon2) без APP_KEY - зміна ключа на них не впливає.

Докладніше в документації: Laravel: ротація ключів шифрування