Same-Site cookies

Same-Site cookies — это настройка атрибута SameSite для cookies с подбором значения под ваши сценарии: Lax (разумный баланс, cookie не уходит при большинстве межсайтовых запросов), Strict (максимально строго, но ломает переходы по внешним ссылкам с авторизацией), None (нужно для легитимных межсайтовых сценариев — но требует Secure). Честно про область, это важно: SameSite снижает риск CSRF (межсайтовой подделки запроса), это весомый современный механизм, но НЕ полная защита от CSRF сам по себе: для чувствительных действий по-прежнему нужны анти-CSRF токены (751) — это защита в несколько слоёв, а не «поставили SameSite и забыли». Честно про совместимость, это ключевое: неверное значение ломает легитимные межсайтовые сценарии — встроенные платёжные формы, виджеты, вход через сторонний домен (OAuth), iframe-интеграции. Поэтому подбираем значение под КАЖДУЮ cookie и сценарий, а не ставим Strict «на всё». Честно про предпосылку: SameSite=None требует Secure (а значит HTTPS — 736). Честно про доступ: нужен доступ к коду/конфигу, где ставятся cookies. Честно про платформу: на части конструкторов/SaaS (Tilda, Wix, Shopify и т.п.) прямого доступа к атрибутам cookies может не быть — заранее проверяем, возможно ли внедрение именно у вас, и если нет — честно скажем. Честно про область во времени: настройка распространяется на СУЩЕСТВУЮЩИЕ cookies и сценарии; при добавлении новых функций/cookies потребуется повторная корректировка. Честно про проверку: часть пограничных сценариев проявляется только на реальных пользователях после внедрения — мы тестируем и разбираем с вами, но итоговая проверка во всех бизнес-сценариях требует вашего участия. Важная граница: это атрибут SameSite (анти-CSRF слой), полноценные токены — 751, флаги HTTPOnly/Secure — 758. Представьте: вместо «чужой сайт шлёт запрос с вашей cookie от имени пользователя» — браузер сам не отдаёт cookie на межсайтовые запросы. Базовая цена — от 9 000 ₽ за проект.

• Cookie уходит на межсайтовые запросы — риск CSRF.
• Атрибут SameSite не выставлен или выставлен наугад.
• Strict «на всё» ломает входы по внешним ссылкам и интеграции.
• Платёжки/виджеты ломаются из-за неверного SameSite.

• Аудит cookies и межсайтовых сценариев (платёжки, OAuth, виджеты)
• Подбор значения SameSite под каждую cookie (Lax/Strict/None)
• Установка Secure для cookies с SameSite=None
• Проверка, что легитимные межсайтовые сценарии не сломались
• Указание границ (не заменяет анти-CSRF токены)
• Связка с токенами (751) при необходимости
• Проверка применения
• Передача и разбор с вами

• Cookies не уходят на лишние межсайтовые запросы
• Снижен риск CSRF на уровне браузера
• Легитимные интеграции (платёжки/OAuth) сохранены
• Весомый слой анти-CSRF (полная защита — с токенами)

• Снимаем cookies и все межсайтовые сценарии; собираем доступ
• Подбираем SameSite под каждую cookie, ставим, проверяем интеграции
• Проверяем, что ничего не сломалось, разбираем границы с вами

• SameSite полностью защитит от CSRF?

  Нет, сам по себе — нет. SameSite — весомый современный слой (браузер не отдаёт cookie на межсайтовые запросы), но для чувствительных действий по-прежнему нужны анти-CSRF токены (751). Правильно — несколько слоёв вместе, а не «поставили SameSite и забыли».

• Ставим Strict на всё — будет безопаснее?

  Безопаснее, но Strict «на всё» ломает легитимные сценарии: переход по внешней ссылке с авторизацией, вход через сторонний домен (OAuth), встроенные платёжки. Поэтому подбираем значение под каждую cookie и сценарий: где-то Lax, где-то Strict, где-то None+Secure.

• Чем это отличается от защиты от CSRF (751)?

  751 — это анти-CSRF токены в самом приложении (полноценная защита действий). Эта услуга — атрибут SameSite на уровне браузера (дополнительный слой). Их логично делать вместе; честно скажем, нужен ли вам только SameSite или связка с токенами.