Можно ли поставить cookie на subdomen?

Можно ли установить cookie на subdomain?

Да, установить cookie на субдомен можно, и это фундаментальная возможность протокола HTTP и механизма кук. Однако, в зависимости от установленных атрибутов, поведение и доступность куки могут различаться между основным доменом, субдоменами и другими доменами. Ключевую роль здесь играют атрибуты Domain и Secure.

Механизм работы и атрибуты

По умолчанию, если атрибут Domain не указан при установке куки, она считается "host-only". Это означает, что такая кука будет привязана только к точному доменному имени, с которого она была отправлена, и не будет доступна для субдоменов.

Для того чтобы кука была доступна на субдоменах, необходимо явно указать атрибут Domain. Он задаёт домен, для которого кука действительна. Если установить Domain=example.com, то кука будет доступна:

• Для основного домена: example.com
• Для любого его субдомена: app.example.com, api.example.com, blog.example.com
• Важно: Вы не можете установить куку для домена более высокого уровня, чем текущий (например, с sub.example.com нельзя установить куку для other.com или просто .com).

Примеры кода

Установка куки с JavaScript:

// Кука БУДЕТ доступна на субдоменах, так как указан атрибут Domain
document.cookie = "sessionId=abc123; domain=.example.com; path=/; max-age=3600; Secure; SameSite=Lax";

// Кука НЕ БУДЕТ доступна на субдоменах (host-only кука)
document.cookie = "userPref=dark; path=/; max-age=86400";

Установка куки с помощью заголовка Set-Cookie на сервере (Node.js/Express):

app.get('/set-cookie', (req, res) => {
    // Устанавливаем куку, доступную для основного домена и всех субдоменов
    res.setHeader('Set-Cookie', [
        'authToken=xyz789; Domain=.example.com; Path=/; HttpOnly; Secure; SameSite=Strict; Max-Age=7200'
    ]);
    res.send('Cookie set for domain and subdomains!');
});

Ключевые атрибуты безопасности, влияющие на куки для субдоменов

• Secure: Этот атрибут обязателен для современных приложений. Он гарантирует, что кука будет передаваться только по защищённому протоколу HTTPS. Без него браузеры могут блокировать куки, особенно в строгих контекстах.
• HttpOnly: Запрещает доступ к куке через JavaScript на клиенте (document.cookie), защищая от атак межсайтового скриптинга (XSS). Это важный атрибут для кук, содержащих идентификаторы сессий или токены аутентификации.
• SameSite: Современный и критически важный атрибут, который контролирует, отправляется ли кука с межсайтовыми запросами.

    *   `SameSite=Strict`: Кука не будет отправляться ни в каких межсайтовых контекстах. Если пользователь переходит по ссылке с `blog.example.com` на `app.example.com`, куки с `SameSite=Strict`, установленные для `.example.com`, **не будут отправлены**. Это самый безопасный, но иногда неудобный вариант.
    *   `SameSite=Lax` (значение по умолчанию в современных браузерах): Кука отправляется с безопасными (GET) межсайтовыми запросами верхнего уровня (например, при переходе по ссылке). Это удобно для навигации между субдоменами.
    *   `SameSite=None`: Кука отправляется со всеми межсайтовыми запросами. **Для работы этого значения обязательно должен быть установлен атрибут `Secure`**. Это необходимо для функциональности, встроенной в iframe на других доменах, или для запросов с frontend-приложения, размещённого на другом домене, к вашему API на субдомене.

Практические сценарии использования

1. Единая аутентификация (Single Sign-On - SSO): Это классический пример. Пользователь логинится на auth.example.com, где устанавливается кука сессии с Domain=.example.com. Затем, при посещении app.example.com или shop.example.com, эта же кука отправляется браузером, позволяя серверу распознать аутентифицированного пользователя без необходимости повторного ввода логина и пароля.
2. Общие настройки пользователя: Предпочтения языка, темы оформления или региональные настройки, установленные на одном субдомене, могут быть автоматически применены на других, если кука установлена для основного домена.
3. Отслеживание аналитики в рамках одного домена: Сервисы аналитики могут использовать куку, доступную на всех субдоменах, для отслеживания поведения пользователя на всём сайте как на едином ресурсе.

Важные ограничения и предостережения

• Безопасность: Широкое использование кук, доступных для всех субдоменов, увеличивает поверхность атаки. Если один из субдоменов уязвим (например, к XSS), атакующий может скомпрометировать куку, которая затем будет использована на других, более важных субдоменах (например, admin.example.com).
• Политика Same Origin Policy (SOP): Несмотря на общие куки, JavaScript-код, исполняемый на разных субдоменах, по-прежнему считается имеющим разное происхождение (origin). Для взаимодействия между скриптами на разных субдоменах потребуется явное разрешение через CORS (Cross-Origin Resource Sharing) или другие механизмы.
• Указание родительского домена: При установке куки с Domain=example.com она также становится доступной на основном домене. Нельзя установить куку ТОЛЬКО для всех субдоменов, исключив основной.

Заключение: Установка и использование кук на субдоменах — это мощный стандартный механизм, который при правильной настройке (особенно атрибутов Domain, Secure и SameSite) позволяет создавать удобные и функциональные кросс-доменные взаимодействия в рамках одного корневого домена, такие как системы единого входа. Однако его использование требует тщательного учёта вопросов безопасности, чтобы не ослабить защиту всего доменного пространства.