Cookies, сесії та безпека вебсайтів: як сайти запам'ятовують користувачів і захищають їхні дані.

1. Чому сайт повинен запам'ятовувати користувача?

Уявімо, що ти відкрив інтернет-магазин, увійшов до свого облікового запису, переглянув товари, додав декілька позицій у кошик, а потім перейшов на іншу сторінку.

Ти очікуєш, що сайт пам'ятатиме, хто ти та які товари вибрав.

Але тут виникає цікаве технічне питання.

HTTP є протоколом без збереження стану (stateless).

Це означає, що кожен HTTP-запит сам по собі є окремою операцією. Сервер не зобов'язаний автоматично пам'ятати, що саме цей браузер робив хвилину тому.

Наприклад:

1. Браузер надсилає запит на головну сторінку.

2. Сервер повертає сторінку.

3. Браузер надсилає запит на каталог товарів.

4. Сервер обробляє його як новий запит.

Для вирішення цієї проблеми використовують cookies, сесії та інші механізми збереження стану.

Вони дозволяють сайту підтримувати інформацію про користувача між окремими HTTP-запитами.

2. Cookies — невеликі дані, які браузер зберігає для сайту

Cookie (кукі) — невеликий фрагмент даних, який вебсайт може попросити браузер зберегти та надсилати назад під час наступних відповідних запитів.

Cookies використовують для різних завдань:

• підтримання авторизації;

• збереження налаштувань користувача;

• запам'ятовування вибору мови;

• збереження інформації про кошик;

• аналітики;

• рекламного відстеження за відповідних налаштувань і дозволів.

Важливо розуміти: cookie — це не окрема програма та не база даних.

2.1. Як браузер отримує cookie?

Розглянемо простий приклад.

Користувач відкриває сайт:

GET / HTTP/1.1

Host: example.com

Сервер повертає відповідь із заголовком Set-Cookie:

HTTP/1.1 200 OK

Content-Type: text/html

Set-Cookie: language=uk

Браузер отримує цю відповідь і зберігає cookie:

language=uk

Тепер під час наступного відповідного запиту браузер може автоматично додати заголовок Cookie:

GET /products HTTP/1.1

Host: example.com

Cookie: language=uk

Сервер отримує інформацію, що для цього браузера було збережено налаштування мови.

Він може використати його, щоб показати сторінку українською.

Отже, основний механізм такий:

• сервер надсилає Set-Cookie;

• браузер зберігає cookie;

• браузер додає відповідний Cookie до наступних запитів;

• сервер читає отримане значення.

2.2. Що може містити cookie?

Cookie складається з назви, значення та додаткових атрибутів.

Наприклад:

Set-Cookie: language=uk; Max-Age=2592000; Path=/; Secure; SameSite=Lax

Розглянемо складові:

Path визначає, для яких шляхів сайту браузер надсилатиме cookie. Наприклад, Path=/ означає, що cookie може надсилатися під час запитів до будь-яких шляхів цього сайту.

Це приклад cookie з налаштуваннями, а не універсальна конфігурація для всіх випадків.

3. Види cookies та їхні властивості

Cookies можуть відрізнятися за призначенням, терміном зберігання та правилами доступу.

3.1. Session Cookies — сеансові cookies

Сеансова cookie зазвичай не має заданого сервером терміну зберігання через Expires або Max-Age.

Браузер зберігає її як cookie поточної сесії браузера.

Наприклад:

Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure

Після завершення сесії браузера така cookie зазвичай видаляється.

Проте важливо: поняття сесії браузера не завжди дорівнює одному відкритому вікну. Деякі браузери можуть відновлювати попередню сесію після перезапуску, тому не варто вважати закриття браузера надійним способом завершення авторизації.

3.2. Persistent Cookies — постійні cookies

Такі cookies мають визначений термін зберігання.

Наприклад:

Set-Cookie: theme=dark; Max-Age=2592000; Path=/

Тут Max-Age=2592000 означає, що cookie може зберігатися 30 днів.

Їх можуть використовувати для збереження:

• обраної теми оформлення;

• мови;

• налаштувань інтерфейсу;

• інших довготривалих параметрів.

Назва «постійна» не означає, що cookie зберігається назавжди. Вона має обмежений термін дії та може бути видалена користувачем або браузером раніше.

3.3. Основні атрибути безпеки cookies

Для захисту cookies використовують спеціальні атрибути.

Secure

Дозволяє надсилати cookie лише через HTTPS-з'єднання.

Це зменшує ризик перехоплення cookie під час передавання незашифрованим HTTP-з'єднанням.

HttpOnly

Забороняє доступ до cookie через JavaScript за допомогою document.cookie.

Наприклад, якщо cookie має атрибут HttpOnly, такий JavaScript не зможе прочитати її значення:

console.log(document.cookie);

Це особливо важливо для cookies, які містять ідентифікатор сесії.

Однак HttpOnly не робить сайт повністю захищеним від XSS. Шкідливий JavaScript, який виконується в межах сайту, усе ще може здійснювати дії від імені користувача, навіть якщо не здатний прочитати саму cookie.

SameSite

Визначає, за яких умов браузер надсилатиме cookie під час запитів, що походять з інших сайтів.

Має три основні значення:

Наприклад:

Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax

Це поширений набір захисних атрибутів для cookie, яка містить ідентифікатор сесії. Конкретні налаштування залежать від архітектури застосунку.

4. Cookies, localStorage та sessionStorage: у чому різниця?

Під час роботи з JavaScript можна зустріти три механізми зберігання даних у браузері:

• Cookies;

• localStorage;

• sessionStorage.

4.1. localStorage

localStorage — механізм браузера для збереження пар ключ-значення.

Дані залишаються доступними після перезавантаження сторінки та зазвичай зберігаються між перезапусками браузера, доки їх не видалять.

Приклад:

localStorage.setItem("theme", "dark");

Ми зберегли значення dark під ключем theme.

Отримати його можна так:

const theme = localStorage.getItem("theme");

console.log(theme);

Видалити окреме значення:

localStorage.removeItem("theme");

Очистити все сховище цього origin:

localStorage.clear();

4.2. SessionStorage

SessionStorage також зберігає пари ключ-значення, але має іншу тривалість життя.

Дані доступні в межах конкретної сесії сторінки — зазвичай до закриття відповідної вкладки або вікна. Водночас перезавантаження сторінки не завершує цю сесію, а браузер може відновити її після перезапуску. 

Приклад:

sessionStorage.setItem("step", "2");

Отримання:

const step = sessionStorage.getItem("step");

console.log(step);

Це може бути зручно для тимчасового збереження стану форми або процесу, який користувач проходить у вкладці.

4.3. Порівняння

Важливий момент щодо безпеки: localStorage і sessionStorage доступні JavaScript-коду, який виконується в межах відповідного origin.

Тому не варто зберігати там паролі, ідентифікатори сесій, токени доступу та інші секрети без належного обґрунтування й захисної архітектури.

Для багатьох браузерних застосунків безпечніше використовувати захищені HttpOnly cookies для зберігання ідентифікатора сесії.

5. Що таке сесія (Session)?

Cookie дозволяє браузеру зберігати та передавати інформацію. Але сама по собі вона не пояснює, як сервер підтримує стан користувача.

Для цього часто використовують сесію (Session).

Сесія — механізм збереження інформації про взаємодію користувача із системою між окремими запитами.

У типовій серверній архітектурі сервер створює сесію та зберігає її дані на своїй стороні.

Наприклад, після входу користувача сервер може зберегти:

• ідентифікатор користувача;

• час створення сесії;

• час останньої активності;

• рівень доступу;

• інші необхідні параметри.

Браузер отримує унікальний ідентифікатор сесії та зберігає його в cookie.

Тобто:

• сервер зберігає інформацію про сесію;

• браузер зберігає ідентифікатор цієї сесії;

• під час наступних запитів браузер надсилає ідентифікатор;

• сервер знаходить відповідну сесію та визначає, хто звернувся.

5.1. Приклад роботи сесії

Уявімо, що користувач входить до інтернет-магазину.

Браузер надсилає дані до backend через HTTPS.

Backend знаходить відповідний обліковий запис і перевіряє пароль.

Наприклад, у сховищі сесій з'являється запис:

Session ID: 8f31a9c2...

User ID: 125

Role: customer

Created: 2026-11-01

Це умовний приклад структури. Реальні ідентифікатори сесій повинні генеруватися за допомогою криптографічно стійкого генератора випадкових чисел.

Вони мають бути достатньо довгими та непередбачуваними — рекомендована ентропія становить щонайменше 128 біт. Ідентифікатор не повинен містити відкритої інформації про користувача. 

HTTP/1.1 200 OK

Set-Cookie: __Host-session=8f31a9c2...; Path=/; Secure; HttpOnly; SameSite=Lax

Браузер зберігає ідентифікатор.

Префікс __Host- є спеціальним механізмом браузера. Він вимагає використання Secure, Path=/ та відсутності Domain. Завдяки цьому cookie прив'язується до конкретного хоста, що допомагає зменшити ризик її підміни з боку інших піддоменів. 

Браузер надсилає новий запит:

GET /products HTTP/1.1

Host: example.com

Cookie: __Host-session=8f31a9c2...

Backend використовує ідентифікатор, щоб знайти відповідний запис у сховищі сесій.

Він бачить, що запит надійшов від користувача з User ID: 125.

Тому сайт може показати персоналізовану інформацію, наприклад ім'я користувача та його кошик.

5.2. Де зберігаються сесії?

Залежно від архітектури застосунку сесії можуть зберігатися:

• в оперативній пам'яті сервера;

• у спеціалізованому сховищі, наприклад Redis;

• у базі даних;

• в інших серверних сховищах.

Для невеликого застосунку може вистачити простого механізму зберігання. Для великих систем важливо враховувати масштабування, доступність та синхронізацію між серверами.

Наприклад, якщо застосунок працює на декількох серверах, усі вони повинні мати можливість перевірити одну й ту саму сесію.

Тому використовують спільне сховище або іншу узгоджену архітектуру.

6. Автентифікація та авторизація

У попередній статті ми коротко познайомилися з двома поняттями. Тепер розглянемо їх детальніше.

6.1. Автентифікація — Authentication

Автентифікація — процес перевірки того, ким є користувач або інша система.

Найпоширеніший приклад — вхід за логіном і паролем.

Умовний процес:

1. Користувач вводить адресу електронної пошти.

2. Вводить пароль.

3. Браузер надсилає дані серверу через HTTPS.

4. Сервер знаходить обліковий запис.

5. Перевіряє пароль.

6. Якщо перевірка успішна, створює сесію або видає інший механізм підтвердження входу.

Автентифікація може здійснюватися не лише за допомогою пароля.

Існують також:

• одноразові коди;

• апаратні ключі безпеки;

• біометричні механізми;

• цифрові сертифікати;

• вхід через зовнішнього провайдера ідентифікації.

6.2. Авторизація — Authorization

Авторизація визначає, які дії дозволено виконувати вже ідентифікованому користувачеві.

Наприклад, в інтернет-магазині можуть бути такі ролі:

Наприклад, звичайний покупець увійшов до системи, проте не має права змінювати ціну товару.

Сервер повинен перевіряти права доступу під час кожної важливої операції. Не можна покладатися лише на те, що frontend приховав кнопку адміністратора.

6.3. Принцип мінімальних привілеїв

Один із базових принципів інформаційної безпеки — надавати користувачеві лише ті права, які необхідні для виконання його завдань.

Наприклад:

• покупцю не потрібен доступ до налаштувань сервера;

• менеджеру не обов'язково мати право створювати облікові записи адміністраторів;

• адміністратор не повинен використовувати один і той самий обліковий запис для всіх повсякденних операцій, якщо система передбачає окремі обмежені ролі.

Це зменшує наслідки помилок і можливих атак.

7. Як система зберігає паролі?

Паролі — одна з найчутливіших категорій даних у вебсистемах.

Під час реєстрації користувач створює пароль, який надалі використовуватиметься для входу.

Виникає запитання: чи зберігає сайт пароль у базі даних у звичайному текстовому вигляді?

Для цього використовують спеціальні алгоритми хешування паролів.

7.1. Що таке хешування?

Хешування (Hashing) — перетворення вхідних даних на результат фіксованого формату за допомогою математичної функції.

Наприклад, пароль:

MyStrongPassword123

Після хешування перетворюється на рядок, який не є початковим паролем.

Хешування паролів має бути спеціально пристосованим до захисту паролів: використовують алгоритми на кшталт Argon2id, bcrypt або scrypt, а також у відповідних випадках PBKDF2.

Звичайні швидкі хеш-функції на кшталт MD5 або SHA-256 не підходять для безпосереднього зберігання паролів.

7.2. Навіщо потрібна сіль (Salt)?

Якщо два користувачі встановлять однаковий пароль, система не повинна зберігати / отримувати однакові результати його хешування. 

Для цього використовують сіль (Salt) — унікальне випадкове значення, яке генерується окремо для кожного пароля та використовується під час його хешування. 

Сіль не потрібно вигадувати вручну: сучасні бібліотеки для хешування паролів зазвичай автоматично генерують і зберігають її разом із параметрами алгоритму та результатом хешування. 

Умовно:

Пароль + Випадкова сіль

          v

   Алгоритм хешування

          v

      Хеш пароля

Сіль зберігається разом із результатом хешування. Її не потрібно приховувати як секрет.

Під час входу сервер повторно виконує перевірку за допомогою збережених параметрів і порівнює результат із тим, що зберігається в базі.

7.3. Як перевіряється пароль під час входу?

1. Користувач вводить пароль.

2. Сервер отримує його через захищене з'єднання.

3. Знаходить запис користувача.

4. Використовує збережену сіль і параметри алгоритму.

5. Перевіряє відповідність пароля збереженому хешу.

6. Якщо перевірка успішна, дозволяє вхід.

Серверу не потрібно знати або відновлювати початковий пароль із хешу.

Важливо також використовувати обмеження частоти спроб входу, захист від автоматизованого підбору паролів та механізми відновлення доступу.

8. Двофакторна та багатофакторна автентифікація

Навіть складний пароль може бути викрадений, повторно використаний на іншому сайті або розкритий через витік даних.

Тому сучасні системи часто використовують багатофакторну автентифікацію.

MFA (Multi-Factor Authentication) — автентифікація за допомогою двох або більше незалежних факторів.

Основні категорії факторів:

1. Те, що ти знаєш — пароль або PIN-код.

2. Те, що ти маєш — фізичний ключ безпеки або пристрій.

3. Те, ким ти є — біометричні характеристики, наприклад відбиток пальця.

2FA (Two-Factor Authentication) — окремий випадок MFA, коли використовуються два фактори.

Наприклад:

• пароль;

• підтвердження входу за допомогою фізичного ключа безпеки.

Або:

• пароль;

• одноразовий код із застосунку-автентифікатора.

Важливо: два паролі не є двофакторною автентифікацією, оскільки обидва належать до однієї категорії — того, що користувач знає.

9. Основні загрози безпеці вебсайтів

Тепер розглянемо найважливіші типи атак, які можуть загрожувати вебзастосункам.

Мета цього розділу — не навчити атакувати сайти, а допомогти зрозуміти, які проблеми повинні враховувати розробники.

9.1. XSS — Cross-Site Scripting

XSS — тип вразливості, за якої зловмисник може домогтися виконання небажаного JavaScript-коду в браузері іншого користувача в контексті вразливого сайту.

Користувач вводить текст, який згодом відображається іншим відвідувачам.

Якщо сайт неправильно обробляє введені дані, замість звичайного тексту браузер може інтерпретувати їх як HTML або JavaScript.

У результаті шкідливий код може виконатися в контексті сторінки.

Можливі наслідки:

• виконання небажаних дій від імені користувача;

• отримання доступу до доступних JavaScript даних;

• підміна вмісту сторінки;

• викрадення інформації, до якої має доступ шкідливий код.

Як захищаються:

• правильно обробляють і кодують користувацький вміст;

• використовують безпечні методи вставлення тексту в DOM;

• уникають небезпечного виконання HTML і JavaScript із неперевірених джерел;

• застосовують Content Security Policy;

• використовують HttpOnly для чутливих cookies.

Важливо: HttpOnly обмежує читання cookie через JavaScript, але не усуває саму XSS-вразливість.

9.2. CSRF — Cross-Site Request Forgery

CSRF — атака, за якої зловмисник намагається змусити браузер авторизованого користувача виконати небажану дію на іншому сайті.

Уявімо:

1. Користувач увійшов до інтернет-банку.

2. Браузер зберіг cookie сесії.

3. Користувач відкрив інший, шкідливий сайт.

4. Цей сайт намагається ініціювати запит до банку.

5. Браузер може автоматично додати відповідну cookie до запиту.

6. Якщо банк не має належного захисту, запит може бути сприйнятий як дія авторизованого користувача.

Саме автоматичне надсилання cookies створює одну з передумов для CSRF.

Захист включає:

• CSRF-токени;

• атрибут SameSite для cookies;

• перевірку джерела запиту через Origin або Referer;

• правильне використання HTTP-методів;

• додаткове підтвердження важливих операцій.

Особливо важливо: операції, які змінюють дані, не повинні виконуватися через звичайний GET-запит.

SameSite є корисним додатковим рівнем захисту, але не замінює повноцінну CSRF-захистну логіку в усіх архітектурах.

9.3. SQL Injection

Ми вже познайомилися із SQL Injection у попередній статті.

Нагадаємо головне: проблема виникає, коли система неправильно формує SQL-запити та дозволяє вхідним даним змінювати їхню структуру.

Захист:

• параметризовані SQL-запити;

• перевірка вхідних даних;

• обмежені права доступу до бази;

• використання надійних бібліотек та ORM;

• відсутність конструювання SQL-команд шляхом небезпечного об'єднання рядків.

9.4. Перехоплення даних — Man-in-the-Middle

Man-in-the-Middle (MitM) — ситуація, коли зловмисник намагається перехопити або змінити інформацію під час її передавання між двома сторонами.

Наприклад, користувач підключається до незахищеної мережі Wi-Fi та відкриває сайт через HTTP.

Для захисту використовують HTTPS, який забезпечує шифрування з'єднання за допомогою TLS.

HTTPS допомагає захищати:

• паролі;

• cookies;

• дані форм;

• вміст HTTP-запитів і відповідей.

Однак HTTPS не захищає від усіх загроз. Він не виправляє помилки в серверній логіці, не усуває XSS і не гарантує безпечність самого сайту.

9.5. Викрадення або підміна сесії

Session Hijacking — ситуація, коли зловмисник отримує доступ до дійсного ідентифікатора сесії та використовує його для імітації авторизованого користувача.

Якщо ідентифікатор сесії потрапив до сторонньої особи, вона може спробувати використати його до завершення або анулювання сесії.

Основні засоби захисту:

• непередбачувані ідентифікатори сесій;

• передавання лише через HTTPS;

• атрибути Secure і HttpOnly;

• обмеження терміну життя сесій;

• завершення сесії після виходу;

• оновлення ідентифікатора після входу та зміни рівня привілеїв;

• захист від XSS та інших способів викрадення даних.

9.6. Brute Force — перебір паролів

Brute Force — метод атаки, за якого зловмисник намагається підібрати пароль шляхом перебору можливих комбінацій.

Для захисту використовують:

• довгі та унікальні паролі;

• обмеження частоти спроб входу;

• тимчасове блокування або додаткову перевірку підозрілих спроб;

• багатофакторну автентифікацію;

• моніторинг незвичайної активності;

• безпечні механізми відновлення пароля.

Не варто покладатися лише на блокування облікового запису після певної кількості помилок: неправильно реалізоване блокування може стати інструментом для відмови в обслуговуванні.

10. HTTPS і TLS: чому захищене з'єднання обов'язкове?

Тепер подивимося на їхню роль у загальній системі безпеки.

HTTP передає дані без вбудованого шифрування транспортного з'єднання.

HTTPS використовує TLS, щоб забезпечити захищений канал між браузером і сервером.

TLS допомагає забезпечити:

Сторонні особи не повинні мати змоги просто прочитати вміст переданих даних.

Дані мають бути захищені від непомітної зміни під час передавання.

Браузер перевіряє сертифікат сервера та встановлює захищене з'єднання з відповідним доменом.

Для сучасних вебсайтів HTTPS необхідний не лише на сторінках входу чи оплати, а для всього сайту.

Це важливо, оскільки cookies сесії та інші чутливі дані можуть передаватися під час звичайної навігації.

Додатково використовують механізм HSTS (HTTP Strict Transport Security). Він повідомляє браузеру, що до сайту потрібно звертатися через HTTPS.

Важливо: HSTS захищає наступні звернення після отримання браузером відповідного заголовка через HTTPS.

Під час першого відвідування сайту браузер може ще не знати про цю політику. Для захисту першого звернення використовують, зокрема, механізм HSTS Preload. 

11. CORS: чому один сайт не завжди може звернутися до іншого?

Під час роботи з API можна зіткнутися з помилкою CORS.

CORS (Cross-Origin Resource Sharing) — механізм браузера, який дозволяє серверу визначати, які запити з інших origin можуть отримувати доступ до його відповідей.

Спочатку розберемо поняття origin.

Origin складається з трьох частин:

• схема — наприклад, https;

• домен — наприклад, example.com;

• порт — наприклад, 443.

Наприклад:

https://example.com

  та

https://api.example.com

мають різні origin, оскільки відрізняються доменами.

Так само різними origin будуть:

http://example.com

https://example.com

Оскільки відрізняються схемами.

Важливо не плутати поняття origin і site. Два ресурси можуть мати різні origin, але належати до одного site. 

Наприклад

https://shop.example.com –

https://api.example.com 

Мають різні origin, проте за звичайних умов вважаються частинами одного site. Саме тому правила CORS і SameSite не можна вважати взаємозамінними. 

11.1. Навіщо потрібен CORS?

Уявімо, що frontend працює на:

https://shop.example.com

А API розміщене на:

https://api.example.com

Браузер застосовує політику одного джерела (Same-Origin Policy), яка обмежує доступ JavaScript до ресурсів іншого origin.

CORS дозволяє серверу API повідомити браузеру, з яких інших origin JavaScript-коду дозволено отримувати доступ до відповідей сервера.

При цьому CORS не обов'язково блокує саме надсилання запиту: у деяких випадках браузер може надіслати його, але не дозволити JavaScript-коду прочитати отриману відповідь. 

Access-Control-Allow-Origin: https://shop.example.com

Це означає, що сервер дозволяє браузеру надати JavaScript-коду з указаного origin доступ до відповіді за відповідних умов.

Важливо розрізняти відправлення запиту та доступ до його відповіді. У деяких випадках браузер може відправити міждоменний запит, але заблокувати JavaScript-доступ до відповіді. 

Для інших типів запитів браузер спочатку виконує попередню перевірку — preflight. Тому CORS не слід сприймати як універсальний механізм блокування сторонніх запитів до сервера.

11.2. Важливі особливості CORS

CORS — це не механізм автентифікації та не заміна авторизації.

Він також не є універсальним захистом сервера від усіх сторонніх запитів.

Якщо сервер дозволяє запити з усіх джерел без обмежень, це може створювати ризики, особливо якщо йдеться про приватні дані та запити з обліковими даними.

Тому CORS потрібно налаштовувати відповідно до архітектури застосунку, дозволяючи лише необхідні джерела, методи та заголовки.

12. Як завершується сесія та чому це важливо?

Вхід до облікового запису — лише початок роботи із сесією.

Не менш важливо правильно завершувати її.

Наприклад, користувач натискає кнопку «Вийти».

Що має відбутися?

1. Браузер надсилає запит на завершення сесії.

2. Сервер знаходить відповідну сесію.

3. Сервер анулює її або видаляє з активного сховища.

4. Браузер отримує інструкцію видалити cookie.

5. Подальші запити зі старим ідентифікатором не повинні надавати доступ.

Приклад запиту:

POST /logout HTTP/1.1

Host: example.com

Cookie: __Host-session=abc123

Сервер може повернути:

HTTP/1.1 200 OK

Set-Cookie: __Host-session=; Path=/; Max-Age=0; Secure; HttpOnly; SameSite=Lax

Max-Age=0 повідомляє браузеру, що cookie потрібно видалити.

Якщо сервер продовжує вважати стару сесію дійсною, зловмисник, який уже отримав її ідентифікатор, потенційно зможе продовжити користуватися нею.

Тому сервер повинен анулювати сесію на своїй стороні.

12.1. Час життя сесії

Сесії можуть мати обмеження за часом.

Найпоширеніші підходи:

Idle Timeout

Сесія завершується після певного періоду бездіяльності.

Наприклад, якщо користувач не виконував жодних дій протягом 30 хвилин, система може попросити його увійти повторно.

Absolute Timeout

Сесія завершується після визначеного часу незалежно від активності.

Наприклад, через 12 годин після створення.

Ці обмеження зменшують ризик використання старої сесії, якщо її ідентифікатор потрапив до сторонньої особи.

Для особливо чутливих операцій система може додатково вимагати повторного підтвердження особи.

13. Практичний приклад: як подивитися cookies у браузері

Тепер перейдемо до невеликої практики.

Ти можеш самостійно подивитися, які cookies використовує відкритий сайт.

Крок 1. Відкрий сайт

Наприклад, відкрий будь-який сайт, який використовує cookies.

Крок 2. Відкрий інструменти розробника

Натисни:

F12

Або:

Ctrl + Shift + I

Крок 3. Перейди до Application

У верхньому меню знайди вкладку Application.

Якщо її не видно, відкрий меню додаткових вкладок.

Крок 4. Знайди Cookies

У лівій панелі знайди:

Storage

   |

   └── Cookies

Натисни на домен сайту.

Крок 5. Переглянь таблицю

Ти побачиш список cookies та їхні властивості.

Зверни увагу на такі стовпці:

• Name — назва;

• Value — значення;

• Domain — домен;

• Path — шлях;

• Expires / Max-Age — термін дії;

• HttpOnly — чи доступна cookie JavaScript;

• Secure — чи обмежене передавання HTTPS;

• SameSite — правила міжсайтового надсилання.

Не змінюй і не копіюй значення авторизаційних cookies для передавання іншим людям. Вони можуть давати доступ до твого облікового запису.

Крок 6. Переглянь HTTP-заголовки

Відкрий вкладку Network.

Онови сторінку та вибери один із запитів.

У розділі Headers можна знайти:

• Set-Cookie — якщо сервер встановлює cookie у відповіді;

• Cookie — якщо браузер надсилає cookie у запиті.

Так можна побачити механізм, який ми розглядали на початку статті, у реальній роботі браузера.

Важливо: не кожен запит містить cookies. Браузер надсилає їх лише за відповідних умов домену, шляху, терміну дії та атрибутів.

14. Загальна схема авторизації та підтримання сесії

Об'єднаємо вивчене в одну послідовність.

Тут видно, як cookies, сесії, автентифікація та авторизація працюють разом.

Кожен механізм виконує окрему функцію:

• cookies допомагають браузеру передавати ідентифікатор;

• сесії дозволяють серверу зберігати стан взаємодії;

• автентифікація перевіряє особу;

• авторизація визначає права;

• HTTPS захищає передавання інформації;

• додаткові механізми безпеки зменшують ризик атак.

15. Типові помилки під час вивчення cookies, сесій та безпеки

Cookie — дані, які зберігає браузер. Сесія — механізм підтримання стану взаємодії, який часто зберігає інформацію на сервері.

HTTP є stateless-протоколом. Для підтримання стану застосовують cookies, сесії та інші механізми.

На відміну від cookies, localStorage не додається автоматично до HTTP-запитів. JavaScript повинен самостійно прочитати його та передати потрібні дані.

Він обмежує читання cookie через JavaScript, але не усуває можливість виконання шкідливого коду на сторінці.

HTTPS захищає канал передавання даних, але не виправляє помилки програмного коду, неправильні права доступу або вразливості бази даних.

Автентифікація перевіряє особу. Авторизація визначає дозволені дії.

Сервер також повинен анулювати відповідну сесію.

Cookies можуть містити чутливі дані. Їх потрібно налаштовувати з урахуванням атрибутів безпеки та правильної архітектури.

CORS регулює доступ браузерного JavaScript до відповідей між різними origin. Він не замінює автентифікацію, авторизацію або серверну перевірку запитів.

16. Підсумок

У цій статті ми розглянули, як вебсайти підтримують стан користувача та захищають його дані.

Основні висновки:

• HTTP є протоколом без збереження стану.

• Cookies дозволяють браузеру зберігати невеликі дані та передавати їх серверу.

• Set-Cookie використовується сервером для встановлення cookie.

• Cookie — заголовок, за допомогою якого браузер надсилає збережені cookies.

• Secure, HttpOnly та SameSite допомагають обмежувати ризики, пов'язані з cookies.

• localStorage і sessionStorage призначені для локального зберігання даних у браузері.

• Сесії дозволяють серверу підтримувати стан взаємодії з користувачем.

• Автентифікація перевіряє особу.

• Авторизація визначає права доступу.

• Паролі потрібно зберігати у вигляді результатів спеціалізованого хешування із сіллю.

• MFA додає додаткові фактори підтвердження особи.

• XSS, CSRF, SQL Injection, MitM та викрадення сесій — важливі загрози веббезпеці.

• HTTPS і TLS захищають передавання даних.

• CORS регулює доступ браузерного JavaScript до відповідей з інших origin.

• Під час виходу сервер повинен анулювати сесію, а не лише видалити cookie.

Тепер ми розуміємо не лише те, як браузер отримує сторінки, як сервер обробляє запити та як бази даних зберігають інформацію, а й те, як вебсистеми впізнають користувачів, підтримують їхній вхід і захищають взаємодію.

17. Словник основних термінів

18. Джерела для подальшого вивчення

Нижче наведені офіційні документації та рекомендації профільних організацій.

1. MDN Web Docs — Using HTTP cookies
   https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies
   Принципи роботи cookies, їх створення, передавання, терміни дії та атрибути.

2. MDN Web Docs — Session Management
   https://developer.mozilla.org/en-US/docs/Web/Security/Authentication/Session_management
   Як працюють сесії, ідентифікатори сесій та механізми їх зберігання.

3. MDN Web Docs — Secure Cookie Configuration
   https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/Cookies
   Практичні рекомендації щодо захищеного налаштування cookies.

4. OWASP — Session Management Cheat Sheet
   https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
   Рекомендації щодо створення, зберігання, захисту та завершення сесій.

5. OWASP — Authentication Cheat Sheet
   https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
   Рекомендації щодо автентифікації, паролів, входу та захисту облікових записів.

6. OWASP — Cross-Site Scripting Prevention Cheat Sheet
   https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
   Як виникають XSS-вразливості та які методи допомагають їх запобігати.

7. OWASP — Cross-Site Request Forgery Prevention Cheat Sheet
   https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
   Механізми захисту від CSRF, CSRF-токени та використання SameSite.

8. OWASP — Password Storage Cheat Sheet
   https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
   Безпечне зберігання паролів, алгоритми хешування та використання солі.

9. OWASP — Transport Layer Security Cheat Sheet
   https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html
   Рекомендації щодо TLS та використання HTTPS у вебзастосунках.

10. MDN Web Docs — CORS
    https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS
    Пояснення Same-Origin Policy, CORS та заголовків контролю доступу.

11. OWASP — Multifactor Authentication Cheat Sheet. Рекомендації щодо факторів автентифікації, MFA та захисту від фішингу.