Cookie

```wiki id="cookie01"

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

У найпростішому сенсі cookie відповідає на питання:

«Як сайт пам’ятає, що це саме ви, що ви вже увійшли в систему, яку мову обрали й які налаштування використовуєте?»

Cookies важливі для вебсайтів, хмарних сервісів, frontend, backend, API, автентифікації, авторизації, ERP, CRM, інтернет-магазинів, особистих кабінетів, державних сервісів, банківських систем і хмарних платформ.

У контексті K2 ERP cookies можуть використовуватися для вебсесій, входу користувача, збереження частини налаштувань, безпечної роботи браузера з хмарною ERP та взаємодії між frontend і backend.

Хмара K2 ERP доступна за адресою:

https://cloud.corp2.eu

Головне. Cookie — це невеликі дані в браузері, які допомагають сайту або вебзастосунку підтримувати сесію, запам’ятовувати налаштування та безпечно взаємодіяти з користувачем.

Застереження. Cookies можуть бути корисними, але якщо сесійна cookie викрадена або залишена на чужому комп’ютері, стороння людина може отримати доступ до облікового запису. Особливо небезпечно це для ERP, банків, пошти та бізнес-систем.

Для K2 ERP. У K2 ERP cookies мають використовуватися обережно й безпечно: для сесій, налаштувань, захищеного входу, роботи браузера та взаємодії з хмарною ERP через HTTPS.

Суть поняття

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

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

Без cookies багато вебсистем були б незручними: сайт не пам’ятав би, що користувач уже увійшов, яку мову обрав, який режим інтерфейсу встановив і які налаштування застосував.

Але cookie — це не печиво до чаю, хоча назва на це натякає. Це маленький технічний запис, який може мати великі наслідки для безпеки.

Навіщо потрібні cookies

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

підтримка входу користувача;
сесії;
мова інтерфейсу;
тема оформлення;
налаштування користувача;
кошик інтернет-магазину;
захист від CSRF;
аналітика;
персоналізація;
технічна робота frontend і backend;
збереження стану між запитами.

У бізнес-системах cookies найчастіше пов’язані з сесіями, автентифікацією, безпекою та налаштуваннями інтерфейсу.

Cookie і Browser

Браузер зберігає cookies для конкретного сайту або домену.

Коли користувач відкриває сайт, браузер може:

отримати cookie від сервера;
зберегти її;
надіслати cookie назад серверу;
обмежити доступ до cookie;
видалити cookie після завершення сесії;
заблокувати сторонні cookies;
показати cookies у налаштуваннях;
очистити cookies за запитом користувача.

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

Cookie і Cache

Cookies і кеш часто плутають, але це різні речі.

Поняття	Що зберігає	Приклад
Cookie	Невеликі дані для сесії, налаштувань або ідентифікації	Session ID, мова інтерфейсу
Cache	Файли або дані для пришвидшення повторного доступу	CSS, JavaScript, зображення, довідники

Cookie допомагає сайту пам’ятати користувача або його стан. Cache допомагає швидше завантажувати ресурси.

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

Cookie і Local Storage

Local storage — інше сховище в браузері.

Cookie автоматично надсилається серверу з відповідними запитами. Local storage зазвичай доступний JavaScript-коду на сторінці й не надсилається автоматично з кожним запитом.

Ознака	Cookie	Local storage
Надсилається серверу автоматично	Так, якщо відповідає домену й правилам	Ні
Часто використовується для сесій	Так	Небажано для чутливих токенів
Може мати HttpOnly	Так	Ні
Доступ із JavaScript	Може бути заборонений через HttpOnly	Так
Типове використання	Сесії, безпека, налаштування	UI-налаштування, локальний стан

Для безпеки сесій cookies часто кращі за local storage, якщо правильно налаштовані прапорці Secure, HttpOnly і SameSite.

Session cookie

Session cookie або сесійна cookie — cookie, яка існує протягом сесії користувача.

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

Session cookie часто використовується для входу в систему.

Наприклад:

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

У хмарній ERP session cookie є критично важливою, бо вона може підтверджувати сесію користувача.

Persistent cookie

Persistent cookie або постійна cookie — cookie, яка має строк дії й може зберігатися після закриття браузера.

Вона може використовуватися для:

запам’ятовування мови;
теми оформлення;
налаштувань інтерфейсу;
функції «запам’ятати мене»;
довших сесій;
аналітики.

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

First-party cookie

First-party cookie — cookie, встановлена сайтом, який користувач безпосередньо відкрив.

Наприклад, користувач відкрив `cloud.corp2.eu`, і цей сайт встановив cookie для своєї роботи.

Такі cookies часто потрібні для нормальної роботи системи: сесії, налаштування, безпека.

Third-party cookie

Third-party cookie — cookie, встановлена стороннім доменом, не тим, який користувач безпосередньо відкрив.

Вони часто використовувалися для:

реклами;
аналітики;
трекінгу;
вбудованих віджетів;
сторонніх сервісів.

Сучасні браузери дедалі сильніше обмежують third-party cookies через приватність і безпеку.

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

Secure cookie

Secure cookie — cookie, яка передається лише через HTTPS.

Це важливий прапорець безпеки.

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

Добра практика. Сесійні cookies у бізнес-системах мають використовувати Secure, щоб не передаватися через незахищений HTTP.

HttpOnly cookie

HttpOnly cookie — cookie, недоступна для JavaScript-коду в браузері.

Це допомагає зменшити ризик викрадення cookie через XSS-атаку.

Якщо cookie зберігає session ID або інший чутливий ідентифікатор, HttpOnly є дуже важливим прапорцем.

Простіше кажучи: браузер може надсилати cookie серверу, але JavaScript на сторінці не може її прочитати.

SameSite cookie

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

Основні значення:

SameSite=Strict;
SameSite=Lax;
SameSite=None.

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

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

Cookie і Authentication

Authentication або автентифікація часто використовує cookies.

Після успішного входу backend може створити сесію й записати session ID у cookie. Далі сервер перевіряє цю cookie й розуміє, хто робить запит.

Cookie в автентифікації може бути пов’язана з:

session ID;
access token;
refresh token;
MFA-станом;
SSO;
remember me;
захистом від CSRF.

Для автентифікації cookies мають бути добре захищені.

Критично. Сесійна cookie фактично може бути ключем до облікового запису. Її потрібно захищати так само серйозно, як пароль або токен.

Cookie і Authorization

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

Cookie може допомагати серверу ідентифікувати сесію, але сама по собі cookie не повинна бути єдиним джерелом прав доступу.

Правильний підхід:

cookie підтверджує сесію;
backend визначає користувача;
backend перевіряє ролі;
backend перевіряє компанію;
backend перевіряє права на дію;
тільки після цього виконує операцію.

Неправильний підхід:

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

Cookie і Backend

У backend cookies обробляються під час HTTP-запитів.

Backend може:

створити cookie;
встановити строк дії;
встановити Secure;
встановити HttpOnly;
встановити SameSite;
перевірити cookie;
видалити cookie;
оновити сесію;
завершити сеанс;
прив’язати cookie до користувача;
перевірити CSRF-токен.

Backend не має сліпо довіряти cookies. Будь-які дані, які приходять від клієнта, потрібно перевіряти.

Cookie і Frontend

У frontend cookies можуть використовуватися для налаштувань або частини стану інтерфейсу.

Але якщо cookie має HttpOnly, JavaScript не може її прочитати. Це добре для безпеки сесії.

Frontend може стикатися з cookies у таких сценаріях:

користувач увійшов у систему;
користувача викинуло через завершення сесії;
мова інтерфейсу збережена;
темна або світла тема збережена;
CSRF-токен потрібен для форми;
браузер блокує сторонні cookies;
SameSite заважає інтеграції;
cookies очищені й користувач вийшов із системи.

Cookie і API

В API cookies можуть використовуватися для автентифікації вебклієнтів.

Наприклад, браузер надсилає API-запит до backend, а cookie сесії додається автоматично.

API може використовувати:

cookie-based authentication;
token-based authentication;
CSRF protection;
SameSite;
CORS;
HttpOnly cookies;
refresh-token cookies.

Якщо API використовується не лише браузером, а й зовнішніми сервісами, cookies можуть бути не найкращим способом. Для зовнішніх інтеграцій часто використовують токени, API-ключі або OAuth-підходи.

Cookie і CSRF

CSRF або Cross-Site Request Forgery — атака, за якої сторонній сайт намагається змусити браузер користувача виконати запит до іншого сайту, де користувач уже авторизований.

Cookies можуть автоматично надсилатися браузером, тому CSRF є важливою темою для cookie-based authentication.

Захист від CSRF може включати:

SameSite cookies;
CSRF-токени;
перевірку Origin;
перевірку Referer;
правильні HTTP-методи;
додаткові підтвердження для критичних дій.

Для ERP CSRF-захист важливий, бо небажаний запит може спробувати змінити документ, налаштування або дані.

Cookie і XSS

XSS або Cross-Site Scripting — атака, за якої зловмисний JavaScript виконується в браузері користувача.

Якщо session cookie доступна JavaScript, XSS може спробувати її викрасти.

Саме тому для сесійних cookies важливий прапорець HttpOnly.

XSS також потрібно запобігати через:

екранування даних;
Content Security Policy;
валідацію введення;
безпечний frontend;
уникнення небезпечного HTML;
оновлення залежностей.

Cookie і CORS

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

Cookies у cross-origin API-запитах потребують особливої уваги.

Потрібно правильно налаштувати:

Access-Control-Allow-Origin;
Access-Control-Allow-Credentials;
SameSite=None;
Secure;
домени;
credentials mode у frontend.

Неправильний CORS може або зламати потрібну інтеграцію, або створити ризик безпеки.

Cookie і HTTPS

Cookies, пов’язані з входом у систему, мають передаватися через HTTPS.

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

Для хмарної ERP HTTPS є обов’язковим.

Якщо бізнес-система просить логін і пароль без HTTPS — це не бізнес-система, а запрошення до проблем.

Cookie і Cloud Computing

У хмарних системах cookies допомагають підтримувати сесії користувачів між браузером і сервером.

Хмарна система може мати:

балансувальник;
кілька backend-серверів;
сесійне сховище;
CDN;
API;
frontend;
мобільні клієнти;
SSO;
різні домени.

У такій архітектурі cookies потрібно налаштовувати правильно: домен, шлях, SameSite, Secure, HttpOnly, строк дії, сесійне сховище й балансування.

Cookie і Load Balancing

Якщо хмарна система має кілька серверів, cookies можуть використовуватися для sticky sessions — прив’язки користувача до конкретного backend-сервера.

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

Для ERP це важливо, бо користувач не має втрачати сесію через перемикання між серверами.

Cookie і ERP

В ERP cookies найчастіше пов’язані з:

входом користувача;
сесією;
мовою інтерфейсу;
налаштуваннями;
безпекою;
CSRF-захистом;
браузерною роботою;
взаємодією frontend і backend.

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

ERP-ризик. Якщо користувач залишив активну сесію ERP на чужому комп’ютері, інша людина може отримати доступ до бізнес-даних. Після роботи на спільному пристрої потрібно виходити із системи.

Cookie у K2 ERP

У K2 ERP cookies можуть використовуватися в браузерній роботі з хмарою.

Можливі сценарії:

session cookie для входу;
збереження мови інтерфейсу;
технічні налаштування frontend;
CSRF-захист;
підтримка авторизованих API-запитів;
робота з HTTPS;
безпечна взаємодія браузера й backend;
завершення сесії після виходу.

Оскільки K2 ERP працює як хмарна ERP-платформа, cookie-безпека є частиною загальної безпеки системи: authentication, authorization, HTTPS, backend validation, ролі, права доступу, логування й контроль сесій.

Cookie і мобільні застосунки

Мобільні застосунки можуть використовувати cookies, web sessions або токени залежно від архітектури.

Якщо мобільний застосунок відкриває web view або працює з web-based authentication, cookies можуть брати участь у вході.

Але мобільні застосунки часто використовують token-based authentication.

Для K2 ERP, яка має мобільні сценарії роботи Android та iOS, важливо, щоб механізм сесій був безпечним і зручним для користувача.

Cookie і десктопні застосунки

Десктопні застосунки також можуть використовувати cookies або аналогічні механізми збереження сесії, якщо працюють із web-компонентами або API.

Для десктопних клієнтів Linux, Windows і macOS важливо:

безпечно зберігати токени або cookies;
не залишати сесію доступною стороннім;
підтримувати вихід із системи;
захищати локальні дані;
працювати через HTTPS;
оновлювати сесії правильно.

Cookie і приватність

Cookies пов’язані з приватністю користувача.

Вони можуть зберігати або допомагати обробляти:

ідентифікатори;
налаштування;
сесії;
аналітичні дані;
поведінку на сайті;
рекламні ідентифікатори;
персоналізацію.

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

Cookie banner

Cookie banner — повідомлення на сайті про використання cookies.

Воно може:

інформувати користувача;
просити згоду;
дозволяти налаштувати категорії cookies;
пояснювати політику приватності;
відокремлювати необхідні cookies від аналітичних або рекламних.

Для бізнес-системи важливо не перетворювати cookie banner на театр із кнопкою «прийняти все» розміром із двері й кнопкою «налаштувати» розміром із мураху. Прозорість — це теж частина довіри.

Необхідні cookies

Необхідні cookies потрібні для роботи системи.

Наприклад:

session cookie;
CSRF cookie;
cookie безпеки;
cookie мови;
cookie технічних налаштувань.

Без них сайт або система може працювати неправильно.

Аналітичні cookies

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

Вони можуть показувати:

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

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

Рекламні cookies

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

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

Cookie і безпека користувача

Користувач має дотримуватися простих правил:

не входити в ERP на чужих комп’ютерах без потреби;
не зберігати пароль у чужому браузері;
після роботи натискати «Вийти»;
не передавати доступ іншим людям;
використовувати індивідуальний обліковий запис;
очищати cookies на спільному пристрої;
використовувати сучасний браузер;
працювати через HTTPS;
не відкривати підозрілі посилання;
увімкнути MFA, якщо доступно.

Cookie може бути маленькою, але наслідки її втрати можуть бути великими.

Cookie і безпека розробки

Розробники мають враховувати:

Secure;
HttpOnly;
SameSite;
CSRF-захист;
правильний domain;
правильний path;
строк дії;
відкликання сесій;
очищення cookie при logout;
захист від session fixation;
захист від XSS;
захист від CSRF;
HTTPS-only;
логування підозрілих сесій.

Cookie і Session Fixation

Session fixation — атака, за якої зловмисник змушує користувача використовувати відому йому session ID.

Захист:

створювати нову session ID після login;
не приймати session ID з ненадійних джерел;
використовувати Secure і HttpOnly;
обмежувати строк дії сесії;
відкликати старі сесії після зміни пароля;
контролювати підозрілу активність.

Cookie і Logout

Logout або вихід із системи має не просто приховати сторінку.

Правильний вихід має:

зробити сесію недійсною на backend;
видалити або прострочити cookie;
очистити чутливий frontend state;
не дозволяти повернутися кнопкою Back до приватних даних;
завершити refresh tokens, якщо вони використовуються;
за потреби записати подію в лог.

У бізнес-системах вихід із системи — це важлива частина безпеки.

Cookie і строк дії

Cookie може мати строк дії.

Варіанти:

до завершення сесії;
кілька хвилин;
кілька годин;
кілька днів;
довший строк для налаштувань.

Для session cookies строк має бути збалансованим: достатньо зручним для роботи, але не надто довгим для безпеки.

ERP-сесія, яка живе вічно, — це зручно лише до першого інциденту.

Cookie і домен

Cookie прив’язується до домену.

Наприклад, cookie для `cloud.corp2.eu` не повинна автоматично надсилатися на сторонні домени.

Правильне налаштування domain допомагає обмежити область дії cookie й зменшити ризики.

Cookie і Path

Path визначає, для яких шляхів сайту cookie буде надсилатися.

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

У великих системах path може допомагати обмежувати cookie, але його не можна вважати основним механізмом безпеки.

Cookie і шифрування

Cookies можуть містити підписані або зашифровані дані.

Підписана cookie дозволяє серверу перевірити, що її не змінили.

Зашифрована cookie приховує вміст від користувача.

Але навіть підписані й зашифровані cookies не варто використовувати як смітник для всіх даних. Не потрібно класти в cookie те, що краще зберігати на сервері.

Cookie і JWT

JWT може зберігатися в cookie або передаватися іншим способом.

Якщо JWT зберігається в cookie, потрібно враховувати:

Secure;
HttpOnly;
SameSite;
строк дії;
refresh;
відкликання;
CSRF;
розмір токена;
ризик витоку.

JWT не є магічним щитом. Неправильно використаний JWT може створити ті самі проблеми, що й будь-який інший токен.

Cookie і Bug report

Якщо проблема пов’язана з cookies, Bug report має містити:

браузер;
чи повторюється проблема в іншому браузері;
чи допомагає очищення cookies;
чи проблема в режимі інкогніто;
чи користувача викидає після входу;
чи працює HTTPS;
чи є помилки в консолі;
чи є проблеми з CORS;
чи включені third-party cookies;
час виникнення;
кроки відтворення.

Приклад:

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

Це одразу підказує команді, де шукати.

Cookie і цифрова незалежність України

Cookies — маленька технічна деталь, але цифрова незалежність складається саме з таких деталей.

Українські хмарні системи мають бути:

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

K2 ERP як українська ERP-платформа має розвивати не лише бізнес-функції, а й культуру безпечної веброботи: sessions, cookies, HTTPS, authentication, authorization, API, logging, privacy.

Cookie і деколонізація обліку

Деколонізація обліку — це відмова від старих залежностей, 1С, BAS, локальних баз і хаотичних підходів до даних.

Перехід у хмару означає нову культуру безпеки:

індивідуальні облікові записи;
безпечні сесії;
cookies з Secure, HttpOnly, SameSite;
MFA;
контроль доступів;
HTTPS;
вихід із системи на чужих пристроях;
журналювання;
відповідальне поводження з даними.

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

Деколонізація через безпеку. Перехід на українську хмарну ERP — це також перехід до сучасної культури сесій, cookies, доступів, ролей і відповідальності за бізнес-дані.

Типові проблеми з cookies

Проблема	Наслідок	Як краще
Cookie не встановлюється	Користувач не може увійти або сесія не працює	Перевірити domain, path, HTTPS, SameSite, CORS
Cookie не видаляється після logout	Ризик залишеної сесії	Робити сесію недійсною на backend і очищати cookie
Немає Secure	Cookie може передаватися незахищено	Використовувати Secure для сесійних cookies
Немає HttpOnly	Cookie може бути доступна JavaScript	Використовувати HttpOnly для session cookie
Неправильний SameSite	Може зламатися інтеграція або CSRF-захист	Налаштовувати SameSite за сценарієм
Надто довгий строк дії	Ризик довгої активної сесії	Балансувати зручність і безпеку
Third-party cookies заблоковані	Вбудовані сценарії можуть не працювати	Мінімізувати залежність від third-party cookies
Користувач залишив сесію на чужому ПК	Ризик доступу сторонніх	Завжди виходити із системи

Коротко

Питання	Відповідь
Що таке Cookie?	Невеликий фрагмент даних, який сайт зберігає в браузері користувача.
Як це українською?	Cookie або кукі.
Для чого потрібні cookies?	Для сесій, входу, налаштувань, мови, безпеки, CSRF-захисту, аналітики та технічної роботи сайту.
Чим cookie відрізняється від cache?	Cookie зберігає невеликі дані стану або сесії, cache зберігає файли й ресурси для швидшого доступу.
Що таке session cookie?	Cookie, яка використовується для сесії користувача.
Що таке HttpOnly?	Атрибут, який забороняє JavaScript читати cookie.
Що таке Secure?	Атрибут, який дозволяє передавати cookie лише через HTTPS.
Що таке SameSite?	Атрибут, який обмежує надсилання cookie між сайтами й допомагає захищатися від CSRF.
Чому cookies важливі для ERP?	Вони можуть підтримувати сесію користувача, а ERP містить критичні бізнес-дані.
Як cookies пов’язані з K2 ERP?	K2 ERP як хмарна ERP може використовувати cookies для безпечної браузерної роботи, входу, сесій і налаштувань.

Висновок

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

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

Але в бізнес-системах cookie — це не дрібниця. У хмарній ERP сесійна cookie може бути ключем до документів, клієнтів, товарів, звітів, файлів і ролей користувача. Тому cookies мають бути захищені, правильно налаштовані й зрозуміло керовані.

У K2 ERP cookies є частиною ширшої системи безпеки: HTTPS, authentication, authorization, backend validation, ролі, доступи, журналювання, сесії й відповідальне поводження з даними.

Правильний підхід. Cookies для бізнес-систем мають бути мінімальними, захищеними, зрозумілими, з правильними Secure, HttpOnly, SameSite, строком дії та очищенням після logout.

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

Див. також

Зовнішні посилання

Джерела

```