Руководство по работе с Cookie в Laravel 11+

Cookies – это небольшие данные, которые сервер сохраняет на стороне клиента (в браузере) для последующего использования. Laravel предоставляет удобные инструменты для установки, получения и удаления cookie, включая автоматическое шифрование для безопасности. В этом руководстве мы подробно рассмотрим работу с cookie в Laravel 11 и выше, включая примеры кода для контроллеров, middleware и хелперов, различия между зашифрованными и обычными cookie, настройку срока действия и флагов безопасности (Secure, HttpOnly, SameSite), а также использование «отложенных» cookie (queued cookies) и удаление cookie.

1. Работа с cookie в контроллерах, middleware и хелперах

Laravel позволяет работать с cookie практически в любом месте приложения – в контроллерах, middleware (посредниках) и даже в шаблонах или сервис-провайдерах. Рассмотрим основные способы установки и чтения cookie.

Установка и получение cookie в контроллере

В контроллере вы можете установить cookie несколькими способами:

• Через ответ (Response) – Laravel позволяет прикрепить cookie к HTTP-ответу. Например, метод withCookie() у объекта Response или цепочный метод cookie() у помощника response():

use Illuminate\Http\Response;
use Illuminate\Support\Facades\Cookie;
use Illuminate\Http\Request;

public function setCookie(Request $request)
{
    $minutes = 60;
    $response = new Response('Hello, world');
    // Добавляем cookie к ответу с помощью хелпера cookie()
    $response->withCookie(cookie('site_theme', 'dark', $minutes));
    return $response;
}

В примере выше создается новый Response с текстом, затем с помощью глобального хелпера cookie('name', 'value', minutes) генерируется cookie (на 60 минут) и добавляется в ответ методом withCookie(). После возвращения ответа Laravel отправит заголовок Set-Cookie браузеру.

Альтернативно, можно использовать цепочку на response() хелпере:

return response('Cookie set!')->cookie('promo_code', 'XYZ123', 120);

Метод response()->cookie(...) прикрепляет cookie напрямую к создаваемому ответу JSON, View или обычному текстовому ответу.

• С помощью фасада Cookie – Вы можете использовать фасад Cookie для прямой установки. Метод Cookie::queue() ставит cookie в очередь на отправку вместе с ответом:

use Illuminate\Support\Facades\Cookie;

public function setCookieViaFacade()
{
    // Помещаем cookie в очередь на отправку (120 минут)
    Cookie::queue('user_id', '42', 120);
    return redirect('/')->with('status', 'Cookie queued');
}

Вызывая Cookie::queue('имя', 'значение', минуты), мы не отправляем cookie мгновенно, а информируем Laravel добавить этот cookie к исходящему ответу автоматически. За это отвечает middleware Laravel – после выполнения контроллера отложенные cookie будут добавлены к заголовкам ответа. Такой подход удобен, если вы не напрямую возвращаете Response (например, делаете redirect): queued cookie всё равно отправятся.

Для чтения (получения) cookie в контроллере есть два основных способа:

• Через объект запроса. Если контроллер получает объект Request, можно использовать метод $request->cookie('name') для получения значения cookie:

public function getCookie(Request $request)
{
    $value = $request->cookie('site_theme');
    echo $value;
}

• Через фасад Cookie. Фасад также предоставляет метод Cookie::get('name') для получения значения:

$value = Cookie::get('user_id');

Оба способа возвращают расшифрованное значение cookie (о шифровании ниже). При работе в веб-приложении Laravel дешифрует значения автоматически через middleware EncryptCookies. Например, если ранее вы сохранили cookie 'user_id' = 42, то $request->cookie('user_id') вернет строку "42", а не зашифрованный текст. Дополнительная расшифровка не требуется – попытка явно расшифровать (Crypt::decrypt или подобное) приведет к ошибке, так как Laravel уже сделал это.

Работа с cookie в Middleware

В кастомном middleware (посреднике) можно проверять наличие и значения cookie в входящем запросе, а также добавлять cookie в исходящий ответ. Чтобы читать cookie, используйте те же методы, что и в контроллере: $request->cookie('name') или Cookie::get('name'). Эти методы доступны внутри метода handle() middleware, поскольку запрос уже прошел через EncryptCookies и cookie к этому моменту расшифрованы.

Пример: middleware, который устанавливает cookie, если его еще нет:

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;

class UuidMiddleware
{
    public function handle(Request $request, Closure $next)
    {
        // Если cookie 'uuid' уже существует, просто продолжаем обработку
        if ($request->hasCookie('uuid')) {
            return $next($request);
        }

        // Иначе генерируем UUID и устанавливаем cookie навсегда
        $response = $next($request);
        $uuid = (string) \Str::uuid();
        return $response->cookie('uuid', $uuid, 525600, "/");
    }
}

В данном middleware сначала проверяется наличие cookie 'uuid'. Если его нет, после выполнения основного запроса ($next($request)) мы получаем Response и добавляем к нему cookie с помощью $response->cookie(). Обратите внимание: мы вызываем $next прежде чем устанавливать cookie. Это важно – cookie добавляется к уже сформированному ответу, что позволяет не прерывать выполнение запроса. Вызов $response->cookie('uuid', $uuid, 525600, "/") вернет измененный Response, который содержит Set-Cookie заголовок для нового cookie (срок 525600 минут ≈ 1 год в данном примере). Если бы мы попытались вернуть Response до вызова next, основная логика запроса не выполнилась бы.

Альтернативно, можно использовать Cookie::queue() внутри middleware, вместо прямой модификации Response. В таком случае даже без ручного прикрепления cookie к ответу, Laravel позже сам добавит его в заголовки (при условии, что middleware AddQueuedCookiesToResponse подключено). Но чаще в middleware устанавливают cookie именно после $next($request), как показано выше, для наглядности.

Хелпер cookie() и фасад Cookie

Laravel предоставляет глобальный хелпер cookie() и фасад Cookie для управления cookie:

• Хелпер cookie() – это глобальная функция. Если вызвать ее с параметрами (cookie('name', 'value', $minutes, ...)), она создаст экземпляр объекта Symfony\Component\HttpFoundation\Cookie, который представляет cookie. Этот объект можно затем передать в методы ответа (например, выше мы передавали его в withCookie()). Если же вызвать cookie() без параметров, она вернет экземпляр CookieJar – внутреннего менеджера cookie в Laravel, через который можно, например, вызывать методы вроде cookie()->queue() или cookie()->forever() . Чаще всего достаточно вызывать cookie() с параметрами для создания cookie.

• Фасад Cookie – предоставляет статические методы для работы с cookie, проксирующие вызовы к тому же CookieJar. Основные методы:

  • Cookie::queue($cookie) или Cookie::queue('name', 'value', $minutes, ...) – добавить cookie в очередь на отправку (есть перегрузки для удобства). Этот метод мы уже использовали выше.
  • Cookie::get('name') – получить значение cookie (из текущего запроса).
  • Cookie::has('name') – проверить наличие cookie.
  • Cookie::forget('name') – создать cookie для удаления (об этом далее).
  • Cookie::forever('name', 'value', ...) – создать постоянный cookie, который будет жить очень долго (Laravel считает “forever” 5 лет или 400 дней, в зависимости от версии.

По сути, фасад и хелпер предоставляют схожие возможности. Например, Cookie::make('x', 'y', 10) эквивалентен cookie('x','y',10) – оба создадут объект Cookie на 10 минут. Разница в том, что фасад Cookie часто используют для отложенной отправки (queue), а хелпер – для непосредственной передачи cookie в Response.

Пример комбинации: Вы можете использовать хелпер внутри фасада – Cookie::queue(cookie()->forever('session_id', $sid)); – это положит в очередь бессрочный cookie session_id. Либо, как было в примере middleware выше: $response->withCookie(cookie()->forever('uuid', $uuid));.

2. Отличия между обычными и зашифрованными cookie

Одно из ключевых преимуществ Laravel – автоматическое шифрование cookie. По умолчанию все cookie, создаваемые Laravel, шифруются и подписываются перед отправкой клиенту. Это означает, что их содержимое недоступно для чтения или изменения на стороне клиента: браузер хранит зашифрованную строку. При следующем запросе Laravel расшифрует и проверит подпись – если cookie было подделано, оно будет признано недействительным.

Как Laravel шифрует cookie? В приложении, использующем группу middleware web, по умолчанию подключен посредник EncryptCookies. При исходящем ответе он берет каждый cookie и шифрует его значение (используя сервис шифрования и секретный ключ приложения), а также генерирует подпись HMAC для защиты от подмены. При входящем запросе этот же middleware расшифровывает полученные cookie и проверяет их целостность. Благодаря этому разработчики могут работать с $request->cookie() как с обычными данными, не думая о шифровании – Laravel делает это автоматически . Все cookie в Laravel “непрозрачны” для клиента – пользователь не сможет увидеть исходное значение (например, через инструменты разработчика он увидит не "42", а что-то вроде "eyJpdiI6Ikp...").

Обычные (незашифрованные) cookie. Бывают случаи, когда нужно установить cookie в открытом виде – например, чтобы JavaScript на стороне клиента смог прочитать его. Поскольку шифрованный cookie невозможно прочитать в браузере (не зная ключа и алгоритма), Laravel позволяет отключить шифрование для отдельных cookie.

Для этого используется свойство $except в классе middleware App\Http\Middleware\EncryptCookies. В этот массив можно добавить имена cookie, которые не должны шифроваться. Например, чтобы оставить cookie с именем my_cookie незашифрованным, пропишите в EncryptCookies.php:

protected $except = [
    'my_cookie',
];

После этого Laravel будет отправлять и принимать my_cookie как обычный текст. Вы также можете указать несколько имен в массиве. В Laravel 11+ появилась возможность задавать исключения программно при инициализации приложения, но суть остается той же – вы перечисляете имена cookie, которые не нужно шифровать.

Замечание: По умолчанию Laravel уже исключает из шифрования некоторые служебные cookie, например XSRF-TOKEN (токен CSRF для JavaScript). Это можно увидеть в исходном коде EncryptCookies – там задано $except = ['XSRF-TOKEN'] обычно.

После добавления имени в $except, вы можете устанавливать cookie обычными способами (Cookie::queue, response()->cookie и пр.), и Laravel не будет их шифровать. Например, если promo_code внесен в исключения, то Cookie::queue('promo_code', 'BLACKFRIDAY', 60) запишет на клиент читаемое значение "BLACKFRIDAY", а не зашифрованную абракадабру.

Однако осторожно относитесь к незашифрованным cookie. Клиентская сторона сможет их читать и модифицировать. Если приложение полагается на значение такого cookie (например, идентификатор пользователя или флаг админа), злоумышленник может его подделать. Рекомендуется хранить в открытых cookie только несекретные данные (например, предпочтения интерфейса). Если требуется хранить на клиенте информацию, защищенную от изменений, лучше использовать шифрование (по умолчанию) или, по крайней мере, реализовать собственную цифровую подпись.

Безопасность зашифрованных cookie. Шифрование cookie в Laravel построено на том же механизме, что и функция encrypt()/decrypt(), используя OpenSSL с алгоритмом AES-256-CBC и ключ приложения (APP_KEY). Зашифрованные cookie также содержат HMAC подпись. Это значит, что посторонний не сможет прочитать содержимое cookie, а при попытке изменить шифротекст – проверка подписи обнаружит изменение, и Laravel проигнорирует такой cookie. Практически, шифрованный cookie является защищенным от чтения и подделки – Laravel просто не будет доверять cookie, которые не прошли проверку. Благодаря этому вы можете хранить, например, идентификатор пользователя или даже небольшие конфиденциальные данные в cookie (хотя очень чувствительные данные лучше не хранить на клиенте вообще).

Итог: Обычные cookie удобны для взаимодействия с клиентским скриптом, но уязвимы к подмене. Зашифрованные – безопасны, однако недоступны JavaScript. Выбирайте подходящий вариант, а чаще всего – оставляйте шифрование включенным. Если нужно передать данные в JavaScript, можно воспользоваться альтернативами (например, передать через JSON в код страницы) или создать незашифрованный cookie, но убедиться, что в нем нет ничего критичного.

3. Настройка срока действия и флагов Secure, HttpOnly, SameSite

При создании cookie Laravel позволяет указывать множество параметров: время жизни, путь и домен действия, а также флаги безопасности – Secure, HttpOnly и SameSite. Рассмотрим, как управлять этими параметрами на практике.

Срок действия cookie

Время жизни (expiration) cookie определяет, как долго браузер будет хранить его. В Laravel при установке cookie обычно передаются минуты жизни. Например, Cookie::queue('token', 'abc', 120) создаст cookie на 120 минут (2 часа). По истечении этого времени браузер автоматически удалит cookie.

Если указать значение 0 минут, Laravel создаст session cookie, то есть cookie без срока действия, который браузер будет хранить до закрытия окна/приложения браузера). В PHP это поведение стандартно: “If set to 0 or omitted, the cookie will expire at the end of the session (when the browser closes)” . Таким образом, чтобы сделать cookie, живущий только в рамках текущей сессии браузера, передайте 0 в параметре времени. Например:

// Cookie, который исчезнет при закрытии браузера (сессионный)
Cookie::queue('temp_data', '12345', 0);

Обратная ситуация – “вечный” cookie. Laravel предлагает метод Cookie::forever('name', 'value'), который устанавливает срок ~5 лет (в старых версиях – 5 лет, в новых – 400 дней, что связано с ограничениями браузеров на максимальный срок). Вы можете использовать его для cookies типа “Запомнить меня”. Либо указать большое число минут вручную (например, 6024365 для года).

Важно понимать, что отсчет времени начинается с момента отправки cookie клиенту. Если пользователь не зайдет на сайт до истечения срока, cookie пропадет. Также часы идут по часам клиента (хотя устанавливаем мы срок на сервере). Если нужно изменить время жизни уже установленного cookie, его нужно переустановить с новым сроком (или удалить).

Флаги Secure и HttpOnly

Флаги Secure и HttpOnly повышают безопасность использования cookie, ограничивая доступ к ним.

• Secure: Если установлен флаг Secure, браузер будет отправлять cookie только по защищенному соединению (HTTPS). Такой cookie не уйдет через нешифрованный HTTP, что предотвращает его перехват в открытом виде. В Laravel вы можете включить этот флаг, передав параметр $secure = true при создании cookie (шестой параметр в helper cookie() или Cookie::queue). Пример:

  // Установим cookie, доступный только по HTTPS
  Cookie::queue('session_id', 'XYZ', 60, '/', null, true, true);

Здесь true в позиции $secure означает, что cookie session_id будет отослан браузеру с атрибутом Secure. Примечание: В конфигурации session.php есть настройка session.secure_cookie. Если она включена и приложение работает через HTTPS, Laravel по умолчанию будет помечать сессионные cookie как Secure. Однако для своих cookie вы управляете флагом сами.

• HttpOnly: Этот флаг означает, что cookie недоступен через клиентский скрипт (JavaScript) . Когда cookie имеет HttpOnly, попытка прочитать его в document.cookie на стороне браузера не вернет этот ключ. Это защищает cookie от XSS-атак – даже если злоумышленник внедрит JS-код на страницу, он не сможет вытянуть HttpOnly cookie (например, сессии или JWT токен). В Laravel флаг HttpOnly включен по умолчанию для всех cookie, если явно не указать иное. В методах он обычно соответствует параметру $httpOnly = true. Поэтому, когда вы делаете Cookie::queue('x', 'y', 10), cookie уже будет HttpOnly (если вы не передали false). Отключать HttpOnly имеет смысл только если вы намерены читать cookie через JS. Например, чтобы JS мог прочитать незашифрованный cookie "theme", вы могли бы установить его так:

  Cookie::queue('theme', 'light', 0, '/', null, false, false);
  

  Здесь $httpOnly = false, чтобы убрать HttpOnly. Но будьте осторожны: как только вы снимаете HttpOnly, любое стороннее скриптовое окружение (например, подключенный рекламный скрипт) потенциально может прочитать и передать значение cookie. Поэтому лучше всегда держать важные cookie HttpOnly. В целом, для сессионных идентификаторов и чувствительных данных HttpOnly должен быть включен.

Атрибут SameSite

SameSite – это относительно новый атрибут cookie, регулирующий их отправку в кросс-доменных запросах. Он может принимать значения Lax, Strict или None:

• SameSite=Lax (по умолчанию) – Cookie отправляется браузером при обычной навигации пользователя (например, когда он кликает ссылку с другого сайта на ваш или открывает ваш сайт в закладках). Однако при некоторых типах запросов из внешних контекстов cookie не будет отправлен. В частности, Lax блокирует отправку cookie при вложенных запросах с других сайтов, таких как загрузка изображений через <img> или AJAX-запросов с другого домена, а также при отправке форм методом POST с внешнего сайта. Режим Lax считается безопасным значением по умолчанию, он предотвращает большинство CSRF-атак, позволяя при этом пользователю беспрепятственно переходить по ссылкам. Начиная с Laravel 7+, значение SameSite по умолчанию – Lax (если не указано иное).
• SameSite=Strict – Самый строгий режим. Браузер не будет отправлять cookie ни в каких запросах, инициированных извне, даже если пользователь переходит по ссылке на ваш сайт с другого ресурса. Cookie с SameSite=Strict отправляются только когда запрос происходит в рамках той же самой площадки (например, пользователь уже на вашем сайте и нажимает внутренние ссылки). Этот флаг обеспечивает максимальную защиту от CSRF, но может ухудшить UX в некоторых случаях (например, если у вас настроена авторизация через переход по ссылке с внешнего сайта – Strict-cookie не придут, и пользователь может считаться неавторизованным). Используйте Strict для самых чувствительных cookie, где внешние переходы не нужны.
• SameSite=None – Означает отсутствие ограничений: cookie будет отправляться со всеми запросами, в том числе кросс-доменными (например, запросы к API с другого домена, загрузка ресурса через <iframe> и т.п.). Такой режим нужен, например, для интеграции с сторонними сервисами или если ваше приложение разделено по субдоменам/домекам и нужно делиться cookie. Важно: Браузеры требуют, чтобы cookie с SameSite=None обязательно имели флаг Secure, иначе они попросту игнорируются. То есть, устанавливая None, убедитесь, что включен Secure, иначе cookie не будет сохранен в современных браузерах.

В Laravel указать SameSite можно последним параметром в методах установки cookie. Например:

// Установить cookie, доступный во всех контекстах (None), Secure+HttpOnly
Cookie::queue('api_token', 'secret', 30, '/', null, true, true, false, 'None');

Здесь параметр 'None' задает SameSite=None. Мы также передали true для Secure и HttpOnly, так как None требует Secure. Другой пример – Strict:

return response()->cookie('session', 'abc123', 60, '/', null, false, true, false, 'Strict');

Это отправит cookie с атрибутом SameSite=Strict.

Чтобы задать SameSite по умолчанию для сессионных cookie фреймворка, используется настройка в config/session.php – опция same_site. Вы можете поставить там 'none', 'lax' или 'strict' для cookie сессии приложения. Но для отдельных cookie, устанавливаемых вручную, нужно указывать при создании, как показано выше.

Влияние SameSite: Этот флаг напрямую влияет на защиту от CSRF (межсайтовой подделки запроса). Например, если у вашего сайта есть авторизационный cookie с SameSite=Lax или Strict, то злоумышленник не сможет заставить браузер жертвы отправить этот cookie через кросс-доменную форму или AJAX, затрудняя осуществление CSRF. Однако имейте в виду, что SameSite=None необходим, если вы используете, к примеру, механизм авторизации через cookie в APIs (как Laravel Sanctum при работе с SPA на другом домене) – там SameSite=None; Secure обычно требуется, чтобы фронтенд на другом домене получил cookie.

Пример cookie со всеми атрибутами: Пусть нужно установить cookie token на 1 день, доступный только по HTTPS, недоступный из JS и не отправляемый с внешних сайтов. Это значит: Secure, HttpOnly, SameSite=Strict, время 1440 минут. Код будет:

return response()->json(['status' => 'ok'])
    ->cookie('token', $token, 60 * 24, '/', null, true, true, false, 'Strict');

Такой cookie получит браузер. Расшифруем параметры: имя token, значение переменной $token, срок 1 день, путь / (действует на всем сайте), домен по умолчанию текущий (null), Secure=true (только HTTPS), HttpOnly=true (JS не прочитает), raw=false (не URL-экранировать имя, обычно false) и SameSite='Strict'. В результате Set-Cookie заголовок будет примерно: Set-Cookie: token=<значение>; Expires=<дата>; Path=/; Secure; HttpOnly; SameSite=Strict.

По умолчанию Laravel задает SameSite=Lax, Secure=false, HttpOnly=true для своих cookie, если вы не переопределяете. Эти значения можно изменить в конфигурации или при создании каждого cookie.

Исторически, атрибуты Secure, HttpOnly и SameSite призваны улучшить безопасность cookies:

• Secure защищает от утечки cookie через нешифрованный трафик.
• HttpOnly защищает от кражи cookie через XSS-уязвимости.
• SameSite предотвращает автоматическую отправку аутентификационных cookie в контексте запросов с других сайтов (что блокирует многие CSRF-атаки).

Рекомендуется всегда включать Secure (в production-среде с HTTPS) и HttpOnly для чувствительных cookie. SameSite=Lax сейчас является хорошим дефолтом для большинства ситуаций; Strict можно использовать для особенно чувствительных сценариев, а None – только при необходимости кросс-доменного доступа (не забывая про Secure).

4. Использование отложенных cookie и удаление cookie

Наконец, рассмотрим дополнительные возможности: очередь cookie и их удаление.

Cookie::queue() – отложенная установка cookie

Метод Cookie::queue() мы уже использовали выше, но важно подчеркнуть его предназначение. Он позволяет добавлять cookie без непосредственной привязки к возвращаемому объекту Response. Laravel самостоятельно прикрепит все отложенные cookie к исходящему HTTP-ответу, благодаря middleware AddQueuedCookiesToResponse в группе web. Это удобно, когда, например, в контроллере вы делаете return redirect(...) – при редиректе у вас нет возможности явно модифицировать Response, но вызов Cookie::queue до возврата заставит Laravel сохранить cookie и выдать его клиенту.

Вы можете вызывать Cookie::queue() несколько раз за один запрос – все указанные cookie будут отправлены. Если вызвать Cookie::queue с тем же именем cookie несколько раз, будет учитываться последняя версия (Laravel в CookieJar перезапишет предыдущий в очереди для одного и того же имени и пути).

Помните, что отложенный cookie станет доступен только на следующем запросе. Если вы в рамках одного запроса поставили cookie в очередь и тут же пытаетесь его прочитать через $request->cookie() – вы не получите результата, ведь запрос еще не содержал его. Например:

Cookie::queue('test', '123', 5);
$value = Cookie::get('test'); // скорее всего, все еще null, так как cookie еще не отправлен клиенту

Этот код вернет null (или старое значение cookie, если оно уже было). Новое значение будет сохранено у пользователя и придет обратно только со следующим запросом. Это нормальное поведение HTTP.

Если вдруг вам нужно отменить ранее добавленный в очередь cookie до отправки, у CookieJar есть метод unqueue('name'), который удаляет cookie из очереди (редко используется, но он есть).

Удаление cookie

Удалить cookie на стороне клиента можно только отправив новый cookie с той же парой имя/путь/домен и с истекшим сроком. Когда браузер получает cookie с истекшей датой, он сразу удаляет его. Laravel упрощает эту задачу с помощью метода Cookie::forget('name'). Этот метод создаст cookie с переданным именем, пустым значением и отрицательным временем жизни, фактически “протухший” cookie. Вам осталось только отправить его в ответе или через очередь.

Пример: удалим cookie user_id:

// Способ 1: через очередь
Cookie::queue(Cookie::forget('user_id'));

В этом случае Laravel добавит в очередь cookie с именем user_id и параметрами, указывающими браузеру стереть его. Когда ответ дойдет до клиента, cookie будет удален.

Другой способ – использовать вспомогательный метод Cookie::expire('name'), появившийся в Laravel 10+. Он сразу ставит cookie на удаление в очередь (внутри он просто вызывает queue + forget). То есть Cookie::expire('user_id') эквивалентен примеру выше.

Также можно удалить cookie при возврате ответа, используя метод withCookie или response()->cookie с отрицательным временем. Например:

return redirect('/')->withCookie(cookie('user_id', '', -1));

Здесь мы создали cookie 'user_id' с пустым значением и -1 минутой жизни, и прикрепили его к редирект-ответу. В итоге у клиента этот cookie будет немедленно уничтожен.

Обратите внимание на параметры путь и домен: они должны совпадать с теми, что были у оригинального cookie, иначе удаляемый cookie не “заменит” его. По умолчанию Laravel ставит путь '/' и домен текущего сайта. Если вы явно задавали другие, при удалении укажите их так же.

После удаления cookie с клиентской стороны при следующих запросах он естественно будет отсутствовать. Можно проверить удаление, вызвав $request->cookie('user_id') – он вернет null после удаления (или после того, как браузер перестанет его отправлять).

Итог: Для удаления cookie используйте Cookie::forget() вместе с Cookie::queue() – это простой и надежный способ. Laravel сам позаботится о правильных заголовках. Альтернативно, можно послать cookie с истекшей датой через методы Response. В любом случае, удалить cookie мгновенно на сервере невозможно – мы лишь даем команду браузеру удалить его у себя.

На этом наше руководство подошло к концу. Мы разобрали, как устанавливать и получать cookie в Laravel-контроллерах и middleware, как работают хелперы и фасады для cookie, почему Laravel шифрует cookie и как отключить шифрование при необходимости, а также как настраивать важные атрибуты безопасности cookie и корректно удалять их. Используя эти знания, вы сможете безопасно и эффективно работать с cookie в приложениях Laravel 11+. При соблюдении рекомендаций (Secure, HttpOnly для важных cookie, шифрование по умолчанию, SameSite по необходимости) cookie станут полезным инструментом для сохранения данных сессии, настроек пользователя и других задач веб-разработки. Успехов в кодинге!