Что такое cookies и для чего они используются
Что проверяют
Понимаете ли вы механику HTTP-сессии, даже если пишете не под браузер. На android-собеседовании вопрос всплывает из-за WebView и гибридных экранов: авторизация живёт в нативной части, веб-страница внутри приложения про неё не знает, и починить это без понимания cookie нельзя.
Как отвечать
Cookie это пара имени и значения, которую сервер присылает заголовком Set-Cookie, а клиент возвращает в заголовке Cookie при следующих запросах к тому же домену. HTTP не хранит состояния, cookie и есть способ его добавить.
Ключевые атрибуты назовите своими словами: Domain и Path задают, куда cookie поедет; Expires или Max-Age отличают сессионную от постоянной; Secure запрещает отправку по открытому каналу; HttpOnly прячет значение от JavaScript; SameSite ограничивает отправку при переходах с чужих сайтов и закрывает основную часть CSRF.
Для Android добавьте практику. В нативных запросах OkHttp по умолчанию cookie не хранит вообще, нужен свой CookieJar или обёртка над системным хранилищем. У WebView хранилище отдельное, им управляет CookieManager, и именно туда переносят сессию, чтобы веб-экран открылся уже авторизованным.
CookieManager.getInstance().setCookie("https://example.org", "sid=$token; Secure; HttpOnly")Хороший финал: нативные вызовы чаще ходят с токеном в заголовке Authorization, а cookie остаются там, где есть браузерный контекст.
Где спотыкаются
Называют cookie файлами на диске. Это часть HTTP-заголовков, куда клиент их положит, его дело, а размер одной cookie ограничен несколькими килобайтами, поэтому профиль пользователя в неё не кладут.
Считают HttpOnly защитой от кражи вообще. Он закрывает только доступ из JavaScript, перехват по открытому каналу лечится флагом Secure вместе с HTTPS, а подделка запроса с чужой страницы атрибутом SameSite.
Забывают про очистку при выходе. Логаут в нативной части не трогает хранилище WebView, и следующий пользователь устройства откроет веб-экран под чужой сессией.