Объяснение SameSiteатрибута файлов cookie
Защитите свой сайт, узнав, как явно отмечать межсайтовые файлы cookie.
Файлы cookieэто один из доступных методов добавления постоянного состояния веб-сайтам. С годами возможности cookie росли и развивались, но платформа сохранила часть прежних проблем. Для их решения браузеры (в том числе Chrome, Firefox и Edge) меняют свое поведение, чтобы обеспечить больше устанавливаемых по умолчанию параметров, сохраняющих конфиденциальность.
Каждый файл cookie представляет собой пару key=value , дополненную рядом атрибутов, которые определяют, когда и где используется этот файл cookie. Вероятно, вы уже использовали эти атрибуты, чтобы установить дату истечения срока действия или указать, что файл cookie должен отправляться только по HTTPS. Серверы устанавливают файлы cookie, отправляя в своем ответе заголовок Set-Cookie . Чтобы узнать обо всех подробностях, вы можете погрузиться в RFC6265bis, а пока что краткое напоминание.
Допустим, у вас есть блог, в котором вы хотите показывать своим пользователям рекламу «Что нового». Пользователи могут закрыть рекламу, и не будут видеть ее в течение некоторого времени. Вы можете сохранить это предпочтение в файле cookie, установить для него срок действия в месяц (2600000 секунд) и отправлять файл cooki только по HTTPS. Этот заголовок будет выглядеть так:
Серверы устанавливают файлы cookie с помощью заголовка Set-Cookie .
Когда ваш читатель просматривает страницу, которая соответствует этим требованиям, то есть просматривается в безопасном соединении, а возраст cookie не превышает одного месяца, браузер пользователя отправит этот заголовок в своем запросе:
Браузер отправляет файл cookie обратно в заголовке Cookie .
Вы также можете добавлять и читать файлы cookie, доступные для этого сайта, в JavaScript, используя document.cookie . Запись в document.cookie приведет к созданию или переопределению файла cookie с этим ключом. Например, в консоли JavaScript браузера можно попробовать выполнить следующее:
При чтении document.cookie будут выведены все файлы cookie, доступные в текущем контексте, причем каждый файл cookie разделен точкой с запятой:
JavaScript может получить доступ к файлам cookie с помощью document.cookie .
Если вы попробуете сделать это на нескольких популярных сайтах, вы заметите, что большинство из них устанавливают значительно больше трех файлов cookie. В большинстве случаев эти файлы cookie отправляются при каждом запросе к этому домену, что имеет ряд последствий. Пропускная способность каналов загрузки часто более ограничена, чем каналов скачивания для ваших пользователей, поэтому накладные расходы на все исходящие запросы добавляют задержку к времени до первого байта. Будьте осторожны в выборе количества и размера файлов cookie, которые вы устанавливаете. Используйте атрибут Max-Age , чтобы гарантировать, что файлы cookie не будут храниться дольше необходимого.
Что такое основные и сторонние файлы cookie? #
Если вы вернетесь к предыдущей подборке сайтов, то, вероятно, заметите, что присутствуют файлы cookie для различных доменов, а не только для того, который вы посещаете в данный момент. Файлы cookie, соответствующие домену текущего сайта, то есть тому, что отображается в адресной строке браузера, называются основными файлами cookie. Аналогично, файлы cookie из доменов, отличных от текущего сайта, называются сторонними файлами cookie. Это определение не абсолютное, а зависит от контекста пользователя; один и тот же файл cookie может быть как основным, так и сторонним, в зависимости от того, на каком сайте пользователь находится в данный момент. Файлы cookie могут поступать с разных доменов на одной странице.
Продолжая приведенный выше пример, предположим, что в одном из ваших сообщений в блоге есть изображение изумительно чудесного котика, и оно размещено по адресу /blog/img/amazing-cat.png . Поскольку это изображение такое изумительное, другой человек использует его прямо на своем сайте. Если посетитель был в вашем блоге и у него файл cookie promo_shown , то, когда он просматривает amazing-cat.png на сайте другого человека, этот файл cookie будет отправлен в этом запросе для изображения. Это никому не нужно, так как promo_shown ни для чего не используется на сайте этого человека, он просто добавляет накладные расходы к запросу.
Если это непреднамеренный эффект, то зачем вам это нужно? Именно этот механизм позволяет сайтам сохранять состояние, когда они используются в стороннем контексте. Например, если вы разместите на своем сайте видео с YouTube, посетители увидят в проигрывателе опцию «Посмотреть позже». Если ваш посетитель уже зарегистрирован на YouTube, его сессия будет доступна во встроенном проигрывателе с помощью стороннего cookie, то есть кнопка «Посмотреть позже» просто сохранит видео одним махом, а не предложит ему войти в систему или переместит его с вашей страницы обратно на YouTube. 
Файл cookie в стороннем контексте отправляется при посещении разных страниц.
Одно из культурных свойств Интернета заключается в том, что он по умолчанию считается открытым. Отчасти это позволило многим людям создавать собственный контент и приложения. Однако это также породило ряд проблем, связанных с безопасностью и конфиденциальностью. Атаки с подделкой межсайтовых запросов (CSRF) основываются на том факте, что файлы cookie прикрепляются к любому запросу из заданного источника, независимо от того, кто инициирует запрос. Например, если вы посетите evil.example , он может инициировать запросы к your-blog.example , и ваш браузер с радостью прикрепит связанные файлы cookie. Если ваш блог не будет внимательно следить за тем, как он проверяет эти запросы, то evil.example может инициировать такие действия, как удаление сообщений или добавление собственного контента.
Пользователи также становятся более осведомленными о том, как файлы cookie могут использоваться для отслеживания их активности на нескольких сайтах. Однако до сих пор не существовало способа явно заявить о своих намерениях в отношении файла cookie. Ваш файл cookie
promo_shown должен отправляться только как основной, тогда как сессионный cookie для виджета, предназначенного для встраивания на другие сайты, намеренно предназначен для обеспечения состояния входа в систему в контексте третьей стороны.
Явно укажите использование файлов cookie с помощью атрибута SameSite #
Введение атрибута SameSite (определенного в RFC6265bis) позволяет вам объявить, должен ли ваш файл cookie быть основным или внутрисайтовым. На этом моменте давайте вспомним, что именно означает «сайт». Сайтэто комбинация суффикса домена и части домена непосредственно перед ним. Например, домен www.web.dev является частью сайта web.dev .
Ключевой термин
Список публичных суффиксов public suffix list определяет это, поэтому речь не только о доменах верхнего уровня, таких как .com , но и о сервисах, таких как github.io , что позволяет считать your-project.github.io и my-project.github.io отдельными сайтами.
Ключевой термин
Введение атрибута SameSite в файл cookie предоставляет три различных способа управления этим поведением. Вы можете не указывать атрибут или использовать значения атрибута Strict или Lax , чтобы ограничить файлы cookie внутрисайтовыми запросами.
Если вы установите для атрибута SameSite значение Strict , ваш файл cookie будет отправляться только для внутрисайтовых запросов. Говоря языком пользователей, файл cookie будет отправлен только в том случае, если сайт для файла cookie совпадает с сайтом, который в данный момент отображается в адресной строке браузера. То есть, если файл cookie promo_shown задан следующим образом:
Когда пользователь находится на вашем сайте, файл cookie будет отправлен вместе с запросом, как и ожидалось. Однако при переходе по ссылке на ваш сайт, например, с другого сайта или по электронной почте от друга, при первом запросе файл cookie не будет отправлен. Это хорошо, если файлы cookie относятся к функциям, стоящим за начальной навигацией, например, сменой пароля или совершением покупки, но слишком ограничивает promo_shown . Если ваш пользователь переходит по ссылке на сайт, он хочет, чтобы файл cookie был отправлен, чтобы были применены пользовательские предпочтения.
Именно здесь и приходит на помощь SameSite=Lax , который разрешает доступ к навигации верхнего уровня. Давайте вернемся к приведенному выше примеру статьи о котике, где другой сайт ссылается на ваш контент. Они используют непосредственно вашу фотографию котика и дают ссылку на вашу оригинальную статью.
И файл cookie был задан следующим образом:
Когда читатель находится в блоге другого человека, файл cookie не будет отправлен, если браузер запросит amazing-cat.png . Однако когда читатель перейдет по ссылке на cat.html в вашем блоге, этот запрос будет включать файл cookie. Это делает значение Lax хорошим выбором для файлов cookie, влияющих на отображение сайта, а значение Strict полезным для файлов cookie, связанных с действиями пользователя.
Внимание
Наконец, можно не указывать значение, что ранее было способом неявного заявления о том, что вы хотите, чтобы файлы cookie отправлялись во всех контекстах. В последнем проекте RFC6265bis это делается явным образом путем введения нового значения SameSite=None . Это означает, что вы можете использовать значение None , чтобы четко указать, что вы намеренно хотите, чтобы файл cookie был отправлен в стороннем контексте. Файлы cookie с явно указанным контекстом None , Lax или Strict .
Изменения поведения по умолчанию без атрибута SameSite #
- если у файлов cookie не задан атрибут SameSite , будет считаться, что SameSite=Lax ;
- для файлов cookie с SameSite=None также нужно указывать параметр Secure , что означает, что такой запрос должен приходить только по защищённому каналу.
Chrome реализует это поведение по умолчанию, начиная с версии 84. В Firefox эти ключевые изменения доступны для тестирования, начиная с Firefox 69, и в будущем они будут использоваться по умолчанию. Чтобы проверить это поведение в Firefox, откройте about:config и установите network.cookie.sameSite.laxByDefault . Edge также планирует изменить свое поведение по умолчанию.
SameSite=Lax по умолчанию #
No attribute set
Если вы отправляете файл cookie без заданного значения для атрибута SameSite …
Default behavior applied
Браузер будет обрабатывать этот файл cookie, как если бы было указано SameSite=Lax .
Хотя это и задумывалось для применения более безопасного значения по умолчанию, в идеале вам следует явно задать значение атрибута SameSite , а не полагаться на то, что браузер применит его за вас. Это делает ваше намерение в отношении файлов cookie явным и повышает шансы на согласованное использование в разных браузерах.
Внимание
SameSite=None должен быть безопасным #
Установка cookie без Secure будет отклонена.
Вы должны убедиться, что для значения атрибута SameSite=None задан параметр Secure .
Вы можете протестировать это поведение в Chrome 76, включив about://flags/#cookies-without-same-site-must-be-secure и в Firefox 69, установив в about:config настройку network.cookie.sameSite.noneRequiresSecure .
Уверены, вы захотите применить эту настройку для новых файлов cookie и обновить существующие файлы cookie, даже если срок их действия еще не истек.
Оба эти изменения обратно совместимы с браузерами, которые правильно реализовали предыдущую версию SameSite или просто не поддерживают его. Применяя эти изменения к своим файлам cookie, вы явно указываете на их предполагаемое использование, а не полагаетесь на поведение браузера по умолчанию. Точно так же любые клиенты, которые еще не распознают SameSite=None должны игнорировать его и продолжать работу, как если бы атрибут не был установлен.
Предупреждение
Рецепты cookie SameSite #
Чтобы прочитать подробнее о том, как именно обновить файлы cookie для успешной обработки изменений SameSite=None и о различиях в поведении браузеров, перейдите к следующей статье, Рецепты cookie SameSite.
Благодарим за вклад и отзывы Лили Чен, Мальте Убл, Майка Уэста, Роба Додсона, Тома Штайнера и Вивека Сехара.
Where to add `SameSite=None`?
I got the following code in happening on my site, and I tried my best cant grasp this, so I have a couple questions, please read.
category-search-Forum:1 A cookie associated with a cross-site resource at https://www.google.com/ was set without the `SameSite` attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.
I’ve seen many people speak about this, on stack and other online places, but none have explained exactly how to add SameSite=None .
1 QUESTION: how or where do you add the SameSite=None ?
and looking at the error , what is and ‘Secure’
does that mean SameSite=Secure ?
What is the difference between SameSite=None and SameSite=Secure ?
2 Answers 2
This is actually a server side issue. All it is saying, is that you are using a resource from another site (most often JS or CSS) and that server is attempting to set a cookie; however, it does not have the SameSite attribute set.
This is being done due to:
Today, if a cookie is only intended to be accessed in a first party context, the developer has the option to apply one of two settings (SameSite=Lax or SameSite=Strict) to prevent external access. However, very few developers follow this recommended practice, leaving a large number of same-site cookies needlessly exposed to threats such as Cross-Site Request Forgery attacks.
To safeguard more websites and their users, the new secure-by-default model assumes all cookies should be protected from external access unless otherwise specified. Developers must use a new cookie setting, SameSite=None, to designate cookies for cross-site access. When the SameSite=None attribute is present, an additional Secure attribute must be used so cross-site cookies can only be accessed over HTTPS connections. This won’t mitigate all risks associated with cross-site access but it will provide protection against network attacks.
Beyond the immediate security benefits, the explicit declaration of cross-site cookies enables greater transparency and user choice. For example, browsers could offer users fine-grained controls to manage cookies that are only accessed by a single site separately from cookies accessed across multiple sites.
As your post doesn’t define if you are working server side or client side, my assumption is you are working client side and as such, there isn’t anything you can do about it as that resource needs to update it. HOWEVER, if you are doing server side dev, here is a list of resources for different languages: https://github.com/GoogleChromeLabs/samesite-examples
TLDR; If you are client side dev, then this is because a linked resource does not have this set and there is nothing you can do about it. If you are server side dev, checkout the github link for examples on how to fix this for your site.
Безопасные настройки файлов Cookie для браузеров с защищенными соединениями
В мае 2019 года Google анонсировал безопасную модель нового веб-браузера Chrome с акцентом на улучшенную защиту персональных данных посредством использования обновленной системы классификации файлов Cookie. Данная инициатива входит в постоянную работу Google по улучшению конфиденциальности и безопасности в сети Интернете.
Chrome планирует внедрить по умолчанию новую защиту пользователей от передачи сторонних Cookie и скрытой идентификации во все версии браузеров Chrome 80 и выше начиная с февраля 2020 года. Mozilla и Microsoft также заявили о намерении внедрить новую модель в браузеры Firefox и Edge в сроки, установленные самостоятельно.
В чём разница межсайтовой и внутрисайтовой связи для файлов Cookie
В содержимое веб-сайтов часто включаются внешние сервисы для рекламы, рекомендации по контенту, сторонние виджеты, социальные сети и другие опции. Когда вы просматриваете веб-страницы, внешние службы могут сохранять файлы Cookie в вашем браузере и в дальнейшем могут получать доступ к этим файлам Cookie, чтобы предоставить персональные рекомендации или оценить поведение пользователей. У каждого файла Cookie имеется связанный с ним домен. Если домен, связанный с файлом Cookie, соответствует внешней службе, а не веб-сайту в адресной строке пользователя, это считается межсайтовой (или «сторонней») связью.
Менее очевидные случаи межсайтового использования включают ситуации, когда объект, который владеет несколькими веб-сайтами, использует файлы Cookie с настроенными араметрами. Несмотря на то, что один и тот же объект владеет файлами Cookie и веб-сайтами, это однозначно считается межсайтовой (сторонней) связью, если домен с файлами Cookie не соответствует сайтам, с которых осуществляется доступ к файлам Cookie.
Когда внешний ресурс на веб-странице получает доступ к файлу Cookie, который не соответствует домену сайта — это межсайтовый или «сторонний» контекст. Напротив, доступ к файлам Cookie в контексте одного и того же сайта (или «первого лица») происходит, когда домен файла Cookie совпадает с доменом сайта в адресной строке пользователя. Файлы Cookie одного сайта обычно используются для того, чтобы когда пользователи заходили на отдельные сайты, запоминались индивидуальные предпочтения и поддерживалась аналитика сайта. Когда ресурс на веб-странице получает доступ к файлу Cookie, который соответствует сайту и который посещает пользователь — это контекст того же сайта или «первого лица».
Новая защита сделает файлы Cookie более безопасными и прозрачными
Атрибут SameSite позволяет определить допустимость передачи файлов Cookie, если со стороннего веб-ресурса поступил запрос. Чаще всего файлы Cookie передаются по любому запросу, даже если запрос поступает с другого сайта при помощи загрузки изображения или iframe.
Подобным способом действуют рекламные сети, пытаясь отследить пользователей при посещении разных сайтов. Также аналогичным образом поступают злоумышленники при организации CSRF-атак, как со страниц взломанного сайта направляются запросы на основной сайт, где находится авторизованный пользователь. При этом пользовательский браузер по указанному запросу передаёт сессионные файлы Cookie. Также отправка Cookie на другие сайты будет возможна, когда на страницах с виджетами имеются вставки.
Параметры атрибута «SameSite» позволяют управлять действиями браузера при отправке файлов Cookie. Например, отправлять Cookie только на те запросы, которые получены первоначально с другого сайта.
Атрибут имеет три значения:
- «Strict» — полный запрет на отправку Cookie.
- «Lax» — блокируются некоторые Cookie для запросов между сайтами (изображения или iframe).
- «None» — ограничения на файлы Cookie отсутствуют.
В настоящее время для предотвращения внешнего доступа файл Cookie может иметь только два параметра: «SameSite = Lax» или «SameSite = Strict». Тем не менее только немногие разработчики придерживаются этой практики. В результате для значительного числа файлов Cookie сайты могут подвергаться атакам через подделку межсайтовых запросов (Cross Site Request Forgery).
Чтобы защитить пользователей и сайты, новая модель безопасности по умолчанию защищает все файлы Cookie от внешнего доступа, если не указаны иные параметры. Чтобы назначить файлы Cookie для межсайтового доступа, разработчики должны сделать настройку файлов Cookie и добавить запись «SameSite = None».
При наличии атрибута «SameSite = None» следует использовать дополнительный атрибут Secure, чтобы межсайтовые файлы Cookie были доступны только для HTTPS-соединений. Это поможет защитить от сетевых атак, обеспечит большую прозрачность и у пользователей появится возможность для выбора. Например, в браузерах будут детализированные элементы для раздельного управления разными типами файлов Cookie (доступ только с одного сайта или с нескольких сайтов).
Другие варианты запрещают обработку файлов Cookie для сторонних сайтов по http-протоколу. В перспективе пользователи будут защищены от скрытой идентификации при помощи уникального отпечатка браузера (технология «Browser Fingerprinting»).
В новой версии Chrome у обработчика кнопки Back появится защита от записей, связанных с автоматическими пробросами и манипуляциями с историей посещений, когда возникают искусственные трудности при возвращении пользователей с просматриваемого сайта на исходную (домашнюю) страницу.
Технология Flash будет отключена по умолчанию в настройках «Расширенные — Приватность и безопасность — Свойства сайтов». С 2020 года поддержка Flash будет полностью отключена.
Chrome Enforcement будет действовать с февраля 2020 года
В рамках развития стратегии Google по информационной безопасности в последующих версиях браузера Chrome 80+ изменится технология обработки файлов Cookie и поддержке атрибута SameSite.
- По умолчанию будет включена опция «Same-site-by-default-Cookies».
- Если в заголовке не будет атрибута «SameSite», браузер Chrome без участия пользователей самостоятельно установит значение «SameSite=Lax», что поможет ограничить отправку файлов Cookie для вставок со сторонних сайтов.
- Чтобы снять автоматическое ограничение, владельцы сайтов могут самостоятельно установить значение параметра «SameSite=None».\
- Безопасные настройки будут доступны для внешнего доступа, если они доступны из защищенных соединений. Средства отслеживания состояния платформы Chrome для «SameSite = None» и Secure будут по-прежнему обновляться с использованием последней информации о запуске.
- Mozilla подтвердила свою поддержку новой модели классификации файлов Cookie, намереваясь реализовать атрибут «SameSite = None».
- Microsoft также объявила о планах начать реализацию модели, начиная с браузера Microsoft Edge 80.
Как приготовиться к новым настройкам и преодолеть трудности
Если вы управляете межсайтовыми файлами Cookie, для безопасной настройки файлов Cookie вам необходимо применять атрибут «SameSite = None». Внедрение не должно представлять трудности для большинства разработчиков. Но Гугл настоятельно рекомендует приступить к тестированию без промедления, чтобы заранее выявить сложности и особые случаи. Например, такие как:
- Не все языки и библиотеки поддерживают значение None, что требует от разработчиков непосредственной установки заголовка файлов Cookie. Этот репозиторий Github содержит инструкции по реализации атрибута безопасной настройки «SameSite = None» на разных языках, в библиотеках и фреймворках.
- Некоторые браузеры, включая отдельные версии Chrome, Safari и UC Browser, могут непреднамеренно обрабатывать значение None и это требует от разработчиков кодирования исключений для этих клиентов. Например, для Android WebViews на основе более старых версий Chrome. Вот список известных несовместимых клиентов.
- Разработчикам приложений рекомендуется раскрывать соответствующие настройки файлов Cookie SameSite для веб-приложений Android на основе версий Chrome, которые совместимы со значением None, как для файлов Cookie, доступ к которым осуществляется через заголовки HTTP (S), так и через API-интерфейс Cookie Manager Android WebView. Однако новая модель не будет позже применяться на Android WebView.
- Корпоративным ИТ-администраторам могут потребоваться специальные политики для временного возврата браузера Chrome к прежним настройкам, если некоторые службы, такие как единый вход или внутренние приложения, неготовы к запуску новой модели в феврале 2020 года.
- Если у вас есть файлы Cookie, к которым вы получаете доступ как в первом, так и в стороннем контексте, вы можете рассмотреть возможность использования отдельных файлов Cookie для получения преимуществ безопасности SameSite = Lax в контексте первого лица.
В разъяснениях к SameSite Cookie предлагаются конкретные рекомендации для решения вышеописанных ситуаций, а также каналы для обратной связи. Чтобы проверить влияние новой версии Chrome на ваш сайт или управляемые вами файлы Cookie, вы можете обратиться к настройке «chrome: // flags» в браузере Chrome 76+ и включить опцию «SameSite by default Cookies» и «Cookies without SameSite must be secure».
Кроме того, эти опции будут автоматически включены для некоторых пользователей бета-версии браузера Chrome 79. Некоторые пользователи бета-версии с включенными экспериментальными опциями могут столкнуться с проблемами несовместимости со службами, которые еще не поддерживают новую модель. В этом случае пользователи могут отказаться от данных опций в бета-версии, отключив с помощью настройки «chrome: // flags».
SameSite cookies
Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.
The SameSite attribute of the Set-Cookie HTTP response header allows you to declare if your cookie should be restricted to a first-party or same-site context.
Note: Standards related to the Cookie SameSite attribute recently changed such that:
- The cookie-sending behavior if SameSite is not specified is SameSite=Lax . Previously the default was that cookies were sent for all requests.
- Cookies with SameSite=None must now also specify the Secure attribute (they require a secure context/HTTPS).
- Cookies from the same domain are no longer considered to be from the same site if sent using a different scheme ( http: or https: ).
This article documents the new standard. See Browser Compatibility below for information about specific versions where the behavior changed.
Values
The SameSite attribute accepts three values:
Cookies are not sent on normal cross-site subrequests (for example to load images or frames into a third party site), but are sent when a user is navigating to the origin site (i.e., when following a link).
This is the default cookie value if SameSite has not been explicitly specified in recent browser versions (see the «SameSite: Defaults to Lax» feature in the Browser Compatibility).
Note: Lax replaced None as the default value in order to ensure that users have reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks.
In order to mitigate breakage due to the new default value, browsers may implement a «Lax-Allowing-Unsafe» enforcement mode such that cookies can be sent with top-level cross-site unsafe requests if they are less than 2 minutes old. The Chrome implementation and Firefox implementation of that «Lax-Allowing-Unsafe» enforcement mode should be considered a temporary, transitional measure only.
Strict
Cookies will only be sent in a first-party context and not be sent along with requests initiated by third party websites.
Cookies will be sent in all contexts, i.e. in responses to both first-party and cross-site requests. If SameSite=None is set, the cookie Secure attribute must also be set (or the cookie will be blocked).
Fixing common warnings
SameSite=None requires Secure
Warnings like the ones below might appear in your console:
The warning appears because any cookie that requests SameSite=None but is not marked Secure will be rejected.
To fix this, you will have to add the Secure attribute to your SameSite=None cookies.
A Secure cookie is only sent to the server with an encrypted request over the HTTPS protocol. Note that insecure sites ( http: ) can’t set cookies with the Secure directive.
Note: On older browser versions you might get a warning that the cookie will be blocked in future. For example:
Cookie myCookie will be soon rejected because it has the SameSite attribute set to None or an invalid value, without the secure attribute.
Cookies without SameSite default to SameSite=Lax
Recent versions of modern browsers provide a more secure default for SameSite to your cookies and so the following message might appear in your console:
The warning appears because the SameSite policy for a cookie was not explicitly specified:
You should explicitly communicate the intended SameSite policy for your cookie (rather than relying on browsers to apply SameSite=Lax automatically). This will also improve the experience across browsers as not all of them default to Lax yet.
