Cookie

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

запам’ятовування мови;
теми оформлення;
налаштувань інтерфейсу;
функції «запам’ятати мене»;
довших сесій;
аналітики.; Прозорість — це теж частина довіри.; Будь-які інформаційні дані, які приходять від клієнта, потрібно перевіряти.; Основні значення:

Path визначає, для яких шляхів сайту cookie буде надсилатися.; «Як сайт пам’ятає, що це саме ви, що ви вже увійшли в систему, яку мову обрали й які конфігурація використовуєте?»

CSRF або Cross-Site Request Forgery — атака, за якої сторонній сайт намагається змусити браузер користувача виконати запит до іншого сайту, де користувач системи уже авторизований.; ERP-ризик. Якщо користувач системи залишив активну сесію ERP на чужому комп’ютері, інша людина має змогу отримати доступ до бізнес-даних.; |- | 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 і Authorization

Local storage — інше сховище в браузері.; # Очищати cookies, якщо виникають проблеми з входом.; Якщо API застосовується не лише браузером, а й зовнішніми сервісами, cookies можуть бути не найкращим способом.;== Рекомендації для розробників ==

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

Secure cookie

Вона має змогу використовуватися для:

Cookie сприяє сайту пам’ятати користувача або його стан.;== Cookie і Path ==

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

Головне. Cookie — це невеликі інформаційні дані в браузері, які допомагають сайту або вебзастосунку підтримувати сесію, запам’ятовувати конфігурація та безпечно взаємодіяти з користувачем.; Десктопні застосунки додатково можуть використовувати cookies або аналогічні механізми збереження сесії, якщо працюють із web-компонентами або API.; | Вони можуть підтримувати сесію користувача, а ERP містить критичні бізнес-дані.; Logout або вихід із системи має не без ускладнень приховати сторінку.; # Завершувати сесії після logout.; користувач системи має дотримуватися простих правил: У контексті K2 ERP cookies можуть використовуватися для вебсесій.; Cookies і кеш часто плутають, але це різні речі.; |- | Як це українською?;== Джерела ==

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

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

Правильний підхід: Для ERP це істотно, бо користувач системи не має втрачати сесію через перемикання між серверами.; !;== Суть поняття == Якщо session cookie доступна JavaScript, XSS має змогу спробувати її викрасти.; Якщо користувач системи залишив такий сеанс на чужому комп’ютері, це ризик.; # Вести журнал входів і критичних дій.;== Cookie banner ==

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

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

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

Простіше кажучи: браузер має змогу надсилати cookie серверу, але JavaScript на сторінці не має змогу її прочитати.; ERP-сесія, яка живе вічно, — це комфортно лише до першого інциденту.; SameSite сприяє захищатися від CSRF-атак, коли сторонній сайт намагається змусити браузер користувача виконати небажаний запит до іншого сайту.; У backend cookies обробляються під час HTTP-запитів.; CORS або Cross-Origin Resource Sharing — механізм, який визначає, чи має змогу браузер дозволити вебсторінці робити запити до іншого домену.; Відповідь

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

HTTPS шифрує з’єднання між браузером і сервером, щоб сторонні не могли без зайвих зусиль перехопити cookie, пароль, токен або інші інформаційні дані.; !; У Chrome проблема повторюється, в Firefox ні.; Але якщо cookie має HttpOnly, JavaScript не має змогу її прочитати.; Для автентифікації cookies мають бути добре захищені.; Для бізнес-сайтів і SaaS-сервісів істотно мати зрозумілу політику cookies, особливо якщо використовуються аналітичні або сторонні cookies.; # Використовувати HTTPS.; Для K2 ERP, яка має мобільні сценарії роботи Android та iOS, істотно, щоб механізм сесій був безпечним і зручним для користувача.; завдяки наявності Для користувача це майже невидимо.; Cookies — маленька технічна деталь, але цифрова незалежність складається саме з таких деталей.; Persistent cookie або постійна cookie — cookie, яка має строк дії й має змогу зберігатися після закриття браузера.; Але мобільні застосунки часто використовують token-based authentication.;

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

зручними;
безпечними;
прозорими;
керованими;
захищеними;
зрозумілими для користувача;
професійно реалізованими.; # Використовувати сучасний браузер.; Якщо сайт після актуалізація виглядає дивно — можливо, проблема в cache.; Session cookie часто застосовують, коли потрібно для входу в систему.; з цієї причини cookies мають бути захищені, правильно налаштовані й зрозуміло керовані.;== Third-party cookie ==

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

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

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

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

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

```wiki id="cookie01"

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

Cookie і CORS

!; # Робити сесію недійсною на backend.; Підписана cookie надає можливість серверу перевірити, що її не змінили.; Далі сервер перевіряє цю cookie й розуміє, хто робить запит.; # Налаштовувати SameSite.; |- | Для чого потрібні cookies?; * супровід входу користувача;

сесії;
мова інтерфейсу;
тема оформлення;
конфігурація користувача;
кошик інтернет-магазину;
захист від CSRF;
аналітичні інструменти;
персоналізація;
технічна робота frontend і backend;
збереження стану між запитами.; # Для сесійних cookies використовувати HttpOnly.; # Тестувати cookies у Chrome, Firefox, Safari, Edge та мобільних браузерах.; |-

| Надсилається серверу автономно | Так, якщо відповідає домену й правилам | Ні |- | Часто застосовується для сесій | Так | Небажано для чутливих токенів |- | має змогу мати HttpOnly | Так | Ні |- | Доступ із JavaScript | має змогу бути заборонений через HttpOnly | Так |- | Типове використання | Сесії, безпека, конфігурація | UI-налаштування, локальний стан |}

!; # Використовувати ролі та права на backend.; * session cookie для входу;

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

Cookie banner — повідомлення на сайті про використання cookies.; У багатьох країнах використання cookies регулюється законами про приватність і захист персональних даних.; # Логувати підозрілу сесійну активність.; Але навіть підписані й зашифровані cookies не варто використовувати як смітник для всіх даних.;== HttpOnly cookie ==

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

отримати cookie від сервера;
зберегти її;
надіслати cookie назад серверу;
обмежити доступ до cookie;
видалити cookie після завершення сесії;
заблокувати сторонні cookies;
показати cookies у налаштуваннях;
очистити cookies за запитом користувача.; як ілюстрація, користувач системи відкрив `cloud.corp2.eu`, і цей сайт встановив cookie для своєї роботи.; * інформувати користувача;
просити згоду;
дозволяти налаштувати категорії cookies;
пояснювати політику приватності;
відокремлювати необхідні cookies від аналітичних або рекламних.;== Cookie і домен ==

Backend має змогу:

Cookies пов’язані з приватністю користувача.; https://cloud.corp2.eu

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

зробити сесію недійсною на backend;
видалити або прострочити cookie;
очистити чутливий frontend state;
не дозволяти повернутися кнопкою Back до приватних даних;
завершити refresh tokens, якщо вони використовуються;
за потреби записати подію в лог.;Authorization визначає, що користувач системи має змогу робити після входу.; * індивідуальні облікові записи;
безпечні сесії;
cookies з Secure, HttpOnly, SameSite;
MFA;
контроль доступів;
HTTPS;
вихід із системи на чужих пристроях;
журналювання;
відповідальне поводження з даними.; * cookie-based authentication;
token-based authentication;
CSRF protection;
SameSite;
CORS;
HttpOnly cookies;
refresh-token cookies.;

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

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

Після входу в систему користувача одразу повертає на сторінку login.; # Не довіряти даним із cookie без перевірки.; # Не передавати свій обліковий запис іншим.;== Cookie і безпека користувача == Розробники мають враховувати:

Cookie і XSS

Правильне конфігурація domain сприяє обмежити область дії cookie й зменшити ризики.; У frontend cookies можуть використовуватися для налаштувань або частини стану інтерфейсу.; Хмарна платформа має змогу мати:

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

У бізнес-системах cookies найчастіше пов’язані з сесіями, автентифікацією, безпекою та налаштуваннями інтерфейсу.; Для бізнес-систем SameSite потрібно налаштовувати уважно, щоб одночасно зберегти безпеку й не зламати потрібні інтеграції.; Для зовнішніх інтеграцій часто використовують токени, API-ключі або OAuth-підходи.;== Cookie і Cache ==

Для безпеки сесій cookies часто кращі за local storage, якщо правильно налаштовані прапорці Secure, HttpOnly і SameSite.; | Cookie, яка застосовується для сесії користувача.; # Підписувати або шифрувати cookie, якщо вона містить важливі інформаційні дані.;

|- | Що таке Cookie?;== Cookie і ERP ==

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

Cookie і Load Balancing

Для session cookies строк має бути збалансованим: достатньо зручним для роботи, але не надто довгим для безпеки.; У хмарних системах cookies допомагають підтримувати сесії користувачів між браузером і сервером.; У такій архітектурі cookies потрібно налаштовувати правильно: домен, шлях, SameSite, Secure, HttpOnly, строк дії, сесійне сховище й балансування.; # Робити session rotation після login.; * хмарна інфраструктура K2 ERP

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

Необхідні cookies

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

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

безпечно зберігати токени або cookies;
не залишати сесію доступною стороннім;
підтримувати вихід із системи;
захищати локальні інформаційні дані;
працювати через HTTPS;
оновлювати сесії правильно.; * Secure;
HttpOnly;
SameSite;
строк дії;
refresh;
відкликання;
CSRF;
розмір токена;
ризик витоку.; Після очищення cookies у Chrome проблема зникла.

Воно має змогу:

Якщо бізнес-система просить логін і пароль без HTTPS — це не бізнес-система, а запрошення до проблем.; Саме з цієї причини для сесійних cookies важливий прапорець HttpOnly.; Не потрібно класти в cookie те, що краще зберігати на сервері.; Перехід у хмару означає нову культуру безпеки:

!; Окремо варто відзначити входу користувача, збереження частини налаштувань, безпечної роботи браузера з хмарною ERP і взаємодії між frontend і backend.; | Cookie або кукі.; Вона має змогу зникати після закриття браузера або завершення сеансу, залежно від налаштувань.; Після цього браузер автономно надсилає цю cookie під час звернень до системи, а сервер розуміє, що користувач системи уже автентифікований.; !; Вони можуть зберігати або допомагати обробляти:

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

Cookies можуть містити підписані або зашифровані інформаційні дані.; Без них сайт або платформа має змогу працювати неправильно.;== Cookie і безпека розробки ==

Cookie і HTTPS

!; # Очищати cookie при logout.; * ідентифікатори;

конфігурація;
сесії;
аналітичні інформаційні дані;
поведінку на сайті;
рекламні ідентифікатори;
персоналізацію.; # Документувати cookie-політику.; Session fixation — атака, за якої зловмисник змушує користувача використовувати відому йому session ID.; Проблема

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

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

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

session ID;
access token;
refresh token;
MFA-станом;
SSO;
remember me;
захистом від CSRF.; Можливі сценарії:

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

SameSite cookies;
CSRF-токени;
перевірку Origin;
перевірку Referer;
правильні HTTP-методи;
додаткові підтвердження для критичних дій.; Після успішного входу backend має змогу створити сесію й записати session ID у cookie.; У найпростішому сенсі cookie відповідає на питання:

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

Якщо cookie зберігає session ID або інший чутливий ідентифікатор, HttpOnly є собою дуже важливим прапорцем.; # Не відкривати підозрілі посилання.;== Cookie і Browser ==

Cookie і API

!; # Захищати session cookies.;K2 ERP як українська ERP-платформа має розвивати не лише бізнес-функції, а й культуру безпечної веброботи: sessions, cookies, HTTPS, authentication, authorization, API, logging, privacy.; Аналітичні cookies допомагають збирати статистику використання сайту або сервісу.; Secure cookie — cookie, яка передається лише через HTTPS.; |- | Що таке SameSite?; Backend перевіряє логін і пароль, створює сесію та встановлює cookie.; * до завершення сесії;

кілька хвилин;
кілька годин;
кілька днів;
довший строк для налаштувань.; Неправильно використаний JWT має змогу створити ті самі проблеми, що й будь-який інший токен.; XSS або Cross-Site Scripting — атака, за якої зловмисний JavaScript виконується в браузері користувача.; Local storage

JWT не є собою магічним щитом.; # Використовувати індивідуальні облікові записи.; Session cookie або сесійна cookie — cookie, яка існує протягом сесії користувача.; Приклад

Cookie автономно надсилається серверу з відповідними запитами.; Для хмарної ERP HTTPS є собою обов’язковим.; ```

Session cookie

Критично. Сесійна cookie фактично має змогу бути ключем до облікового запису.; Якщо мобільний застосунок відкриває web view або функціонує з web-based authentication, cookies можуть брати участь у вході.; |- | Що таке HttpOnly?; Застереження. Cookies можуть бути корисними, але якщо сесійна cookie викрадена або залишена на чужому комп’ютері, стороння людина має змогу отримати доступ до облікового запису.; як ілюстрація, cookie має змогу діяти для всього сайту або лише для певного розділу.;

!;

Для ERP та бізнес-систем бажано мінімізувати залежність від сторонніх cookies, особливо в критичних процесах.; Якщо проблема пов’язана з cookies, Bug report має містити:

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

аналітики;
трекінгу;
вбудованих віджетів;
сторонніх сервісів.; !; # Не дозволяти спільні логіни для всіх.; Після роботи на спільному пристрої потрібно виходити із системи.;

Cookie і CSRF

створити cookie;
встановити строк дії;
встановити Secure;
встановити HttpOnly;
встановити SameSite;
перевірити cookie;
видалити cookie;
оновити сесію;
завершити сеанс;
прив’язати cookie до користувача;
перевірити CSRF-токен.; !; | Атрибут, який обмежує надсилання cookie між сайтами й сприяє захищатися від CSRF.; Деколонізація обліку — це відмова від старих залежностей, 1С, BAS, локальних баз і хаотичних підходів до даних.; |-

| Чому cookies важливі для ERP?; Cookie в автентифікації має змогу бути пов’язана з:

як ілюстрація, користувач системи входить у систему.; | Для сесій, входу, налаштувань, мови, безпеки, CSRF-захисту, аналітики та технічної роботи сайту.; # Обмежувати строк життя сесій.; хмарна інфраструктура K2 ERP доступна за адресою: Cookie має змогу мати строк дії.; У K2 ERP cookies можуть використовуватися в браузерній роботі з хмарою.; Для ERP CSRF-захист важливий, бо небажаний запит має змогу спробувати змінити документ, конфігурація або інформаційні дані.; Persistent cookies потрібно використовувати обережно, особливо для входу в систему.; Але в бізнес-системах cookie — це не дрібниця.; # Не працювати з ERP у небезпечних або публічних браузерах без потреби.; # Для сесійних cookies використовувати Secure.; Backend не має сліпо довіряти cookies.; # Підтримувати MFA для важливих ролей.; Потрібно правильно налаштувати:

Third-party cookie — cookie, встановлена стороннім доменом, не тим, який користувач системи безпосередньо відкрив.; Cookie прив’язується до домену.; Але технічно браузер постійно користувачі можуть серверу розуміти контекст користувача.; |- | Що таке session cookie?; |}

Захист від CSRF має змогу включати:

як ілюстрація:

Варіанти:

Стара культура: «у всіх один пароль, бо так зручніше».; Це добре для безпеки сесії.; # Не зберігати секретні інформаційні дані в cookie без потреби.; Особливо небезпечно це для ERP, банків, пошти та бізнес-систем.; Для бізнес-системи істотно не перетворювати cookie banner на театр із кнопкою «прийняти все» розміром із двері й кнопкою «налаштувати» розміром із мураху.; Це сприяє зменшити ризик викрадення cookie через XSS-атаку.; Добра практика. Сесійні cookies у бізнес-системах мають використовувати Secure, щоб не передаватися через незахищений HTTP.; Оскільки K2 ERP функціонує як хмарна ERP-платформа, cookie-безпека є собою частиною загальної безпеки системи: authentication, authorization, HTTPS, backend validation, ролі, права доступу, логування й контроль сесій.;

Аналітичні cookies

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

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

Захист:

SameSite cookie

session cookie;
CSRF cookie;
cookie безпеки;
cookie мови;
cookie технічних налаштувань.; # Перевіряти CSRF-захист.; Ознака

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

Secure;
HttpOnly;
SameSite;
CSRF-захист;
правильний domain;
правильний path;
строк дії;
відкликання сесій;
очищення cookie при logout;
захист від session fixation;
захист від XSS;
захист від CSRF;
HTTPS-only;
логування підозрілих сесій.; * екранування даних;
Content Security Policy;
валідацію введення;
безпечний frontend;
уникнення небезпечного HTML;
актуалізація залежностей.; # Використовувати MFA, якщо доступно.; | Cookie зберігає невеликі інформаційні дані стану або сесії, cache зберігає файли й ресурси для швидшого доступу.; як ілюстрація:

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

Але сучасні системи часто намагаються робити сесії незалежними від конкретного сервера, зберігаючи їх у спільному сховищі.; Поняття ERP містить критичні інформаційні дані: документи, клієнтів, товари, звіти, ролі, файли, інтеграції.; У хмарній ERP сесійна cookie має змогу бути ключем до документів, клієнтів, товарів, звітів, файлів і ролей користувача.; Її потрібно захищати так само серйозно, як пароль або токен.; Це маленький технічний запис, який має змогу мати великі наслідки для безпеки.; {| class="wikitable" style="width:100%;" В API cookies можуть використовуватися для автентифікації вебклієнтів.; # Мати зрозумілу політику cookies і приватності.; # Перевіряти, чи проблема повторюється в режимі інкогніто.; # Після роботи на спільному пристрої натискати «Вийти».; * користувач системи увійшов у систему;

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

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

користувач системи вводить логін і пароль;
backend перевіряє інформаційні дані;
створює сесію;
браузер отримує session cookie;
далі браузер надсилає її з кожним запитом;
платформа розуміє, хто користувач системи.; # Не передавати cookies стороннім доменам без потреби.; Мобільні застосунки можуть використовувати cookies, web sessions або токени залежно від архітектури.;== Cookie і Frontend ==

Коротко

Такі cookies часто потрібні для нормальної роботи системи: сесії, конфігурація, безпека.; {| class="wikitable" style="width:100%;" Cookies у cross-origin API-запитах потребують особливої уваги.; Неправильний CORS має змогу або зламати потрібну інтеграцію, або створити ризик безпеки.; * хмарна інфраструктура K2 ERP

Це важливий прапорець безпеки.; Cookies важливі для вебсайтів, хмарних сервісів, frontend, backend, API, автентифікації, авторизації, ERP, CRM, інтернет-магазинів, особистих кабінетів, державних сервісів, банківських систем і хмарних платформ.; Що зберігає Якщо cookie пов’язана з сесією або входом у систему, вона має передаватися лише через захищене з’єднання.;== Cookie і Authentication ==

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

не приймати session ID з ненадійних джерел;
використовувати Secure і HttpOnly;
обмежувати строк дії сесії;
відкликати старі сесії після зміни пароля;
контролювати підозрілу активність.; * які сторінки відкриваються;
які функції використовуються;
де виникають помилки;
які пристрої застосовуються;
як користувачі взаємодіють із системою.; як ілюстрація, браузер надсилає API-запит до backend, а cookie сесії додається автономно.; Cookies використовуються для різних задач:

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

Cookie і Cloud Computing

Браузер зберігає cookies для конкретного сайту або домену.; Він без ускладнень входить у систему й функціонує.; |-

Як cookies пов’язані з K2 ERP?; * входом користувача; сесією; мовою інтерфейсу; налаштуваннями; безпекою; CSRF-захистом; браузерною роботою; взаємодією frontend і backend.; Cookies допомагають сайту пам’ятати користувача, підтримувати сесію, зберігати конфігурація, захищати форми й забезпечувати нормальну роботу браузерних застосунків.; ERP — це не торговий центр із банерами, а платформа обліку.;== Висновок == API має змогу використовувати: Необхідні cookies потрібні для роботи системи.; Сучасні браузери дедалі сильніше обмежують third-party cookies через приватність і безпеку.; \| K2 ERP як хмарна ERP має змогу використовувати cookies для безпечної браузерної роботи, входу, сесій і налаштувань.; \|-	Чим cookie відрізняється від cache?; Якщо користувача постійно викидає із системи — можливо, проблема в cookie або сесії.; Cookie у K2 ERP У бізнес-системах вихід із системи — це важлива частина безпеки.; У великих системах path має змогу допомагати обмежувати cookie, але його не можна вважати основним механізмом безпеки.; * SameSite=Strict; SameSite=Lax; SameSite=None.;== First-party cookie == Рекламні cookies використовуються для таргетингу, ремаркетингу й рекламної персоналізації.