Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni
🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!24.01.2025
Чому кукі безпечніше?
🥠 Кукі були потрібні до епохи JavaScript, коли серверу потрібно було якось зберігати дані на клієнті. Звісно, зараз у нас на клієнті повноцінні застосунки, тож кому ті архаїчні кукі потрібні?
Втім, насправді в кукі вбудовано багато механізмів захисту, та не всі з них ми взагалі можемо відтворити. Головним чином, це атрибут HttpOnly - кукі з HttpOnly не доступні для клієнтського коду, їх наче немає. А значить, їх неможливо вкрасти ніякою інʼєкцією коду. Що, до речі, чи не найбільш реалістична атака на ваш сайт.
Окрім того, в кук є ще низка атрибутів, яка допомагає захистити їх від помилок - CSRF, пересилання без шифрування тощо. Одним словом, безпека кук — це функція браузера, та нам не потрібно (та не варто) придумувати власні альтернативи.
(Примітка: вкрасти куки через злам браузера або локальний доступ до нього — звісно, можливо. Тільки це не так ймовірно, як інʼєкція.)
До речі, fetch() підтримує кукі, причому опціонально навіть якщо API не на тому ж домені. Єдине, що хтось з того домену повинен куку встановити. На відміну від саморобних токенів, кукі також надсилаються для зображень та інших ресурсів.
По змісту в кук немає різниці з будь-якими іншими токенами — туди можна записати будь-що. Але для автентифікації можна виділити два варіанти: або це випадковий токен, що вказує на стан на сервері, або токен зі змістом.
Мені подобається зберігати стан на сервері, бо це робить кукі повністю непрозорими та не потребує складних механізмів приховування та верифікації змісту. Та й розмір стану на сервері практично не обмежений. (Ось відповідь на Stack Exchange, де про це розповідає.)