Cookie-файлы: как работают, типы, приватность и практика

Cookie — небольшой кусок данных, который сайт кладёт в браузер и потом получает обратно с запросами. Так HTTP, сам по себе «без памяти», начинает узнавать сессию, корзину, язык интерфейса. Ниже — откуда они взялись, как устроены атрибуты, типы (first/third-party, session/persistent), приватность и что делать на стороне пользователя и веб-разработчика.

Краткая история

В 1994 году Лу Монтулли (Netscape) предложил cookie, чтобы браузер хранил состояние между запросами: классический кейс — корзина интернет-магазина без постоянной передачи всего списка товаров в URL. Дальше cookie разошлись шире: логин, персонализация, аналитика, рекламный tracking между сайтами. Появились RFC (в т.ч. RFC 6265) и браузерные политики SameSite, Secure, HttpOnly.

Как это работает

Сервер (или JS) выставляет cookie, браузер сохраняет его и при следующих запросах к подходящему домену/пути добавляет заголовок Cookie. Пример Set-Cookie:

Set-Cookie: sessionid=abc123; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600

Ключевые свойства:

• Имя и значение — текстовые пары; размер ограничен (порядка единиц КБ на cookie, лимит числа cookie на домен у браузера).
• Expires / Max-Age — срок жизни. Без них cookie часто сессионный (живёт, пока открыт «контекст сессии» браузера; детали зависят от браузера и restore-сессий).
• Domain и Path — область видимости: какой хост и какой URL-prefix получат cookie.
• Secure — только по HTTPS.
• HttpOnly — недоступен из document.cookie (снижает ущерб от XSS на session token).
• SameSite (Strict / Lax / None) — когда cookie уходит в cross-site запросах; критично для CSRF и third-party сценариев. None требует Secure.

Типы cookie

По сроку жизни

• Session — без долгого expires; удобны для логина «пока браузер открыт».
• Persistent — с expires/Max-Age: «запомнить меня», язык, настройки UI.

По origin

• First-party — cookie домена, который вы реально открыли в адресной строке. База для auth, CSRF-token, UI-prefs.
• Third-party — cookie чужого домена, встроенного iframe/скриптом (реклама, виджеты, часть аналитики). Именно их режут Safari, Firefox и планы Privacy Sandbox / phase-out в Chromium-мире.

По назначению (часто в баннерах согласия)

• Strictly necessary — сессия, корзина, балансировка, security (без них сайт ломается).
• Functional / preferences — язык, тема, некритичные удобства.
• Analytics — Метрика, GA и аналоги (агрегированное поведение).
• Marketing / advertising — ретаргетинг, attribution, cross-site id.

Конфиденциальность и регулирование

Cookie сами по себе не «шпионский формат», но могут хранить идентификаторы, по которым строят профиль. Поэтому:

• GDPR (ЕС) — обработка персональных данных, правовые основания, прозрачность, часто consent для не-essential cookie.
• ePrivacy Directive — отдельно про хранение/доступ к информации на устройстве пользователя (классика «cookie banner» в EU).
• CCPA/CPRA (Калифорния) — прозрачность, opt-out sale/share, «Do Not Sell/Share» и связанные требования.

На практике владелец сайта: политика cookie, баннер/CMP с категориями, не грузить marketing-скрипты до согласия, документировать сроки и цели. Технически «essential only» до opt-in — нормальный default для EU-трафика.

Управление на стороне пользователя

• Настройки браузера — блокировка third-party, очистка при закрытии, список исключений, просмотр cookie по сайту (Chrome, Firefox, Safari, Edge).
• Расширения — Cookie AutoDelete, uBlock Origin и privacy-наборы: чистка после вкладки, блокировка трекеров.
• Privacy-first браузеры — Brave и др. режут tracking по умолчанию; часть сайтов при этом требует ручного allow для логина/платежей.

Жёсткая блокировка всех cookie ломает логин и корзину. Разумный компромисс: резать third-party и marketing, оставлять first-party session.

Практика для разработчиков

• Session id: Secure + HttpOnly + осмысленный SameSite (часто Lax; для cross-site POST/iframe — None+Secure и отдельная CSRF-защита).
• Не кладите PII и токены API в cookie без необходимости; предпочитайте opaque session id на сервере.
• Короткий Max-Age для чувствительных сессий, refresh/re-auth для долгих.
• Prefix-ы __Host- / __Secure- — дополнительные ограничения Domain/Path/Secure (если браузер поддерживает).
• Учитывайте phase-out third-party: first-party analytics, server-side tagging, Privacy Sandbox topics/attribution (где актуально), согласие пользователя.

Что дальше

First-party cookie никуда не деваются: без состояния web-приложениям тяжело. Под давлением оказываются cross-site идентификаторы. Safari и Firefox давно режут third-party; Chrome/Privacy Sandbox двигаются к моделям без «вечного» third-party id. Параллельно растут server-side и first-party measurement, consent mode у аналитики, partition storage.

Итог: cookie — механизм состояния HTTP, а не синоним «трекинга». Понимание атрибутов, first vs third-party и consent-режимов позволяет и сайту работать предсказуемо, и пользователю не отдавать лишнее.

Источники и ссылки