Правило №1. Делайте все авторизационные куки HttpOnly

Куки с флагом HttpOnly не видны браузерному коду, а отправляются только на сервер. На практике у вас почти никогда нет необходимости получать их содержимое со стороны клиента (если такая необходимость почему-то у вас возникла — пересмотрите архитектуру авторизации, скорее всего, там что-то не так). А вот злоумышленнику, нашедшему XSS — а XSS так или иначе когда-нибудь где-нибудь найдется — отсутствие HttpOnly на авторизационных куках доставит много радости.

Правило №2. Выполняйте действия через POST, защищая случайным ключом

GET — это получение информации. POST — выполнение действия. Это не просто вопрос красоты и кошерности парадигмы, это практический вопрос безопасности, потому что GET выполняется без явного участия пользователя, а на подозрительную отправку POST-запроса браузер обязательно переспросит.

Например, если у вас логаут выполняется путем захода на сферическое /auth/logout, то каждый юзер, увидев невидимую картинку <img src=»/auth/logout»>, будет внезапно разлогинен. И это самое безобидное, ведь могут быть картинки «/comment/add», «/item/vote» или даже «/admin/delete-all-these-users». Если ваш язык и фреймворк смешивает данные из POST и GET (а таких много), всегда проверяйте тип запроса для URL действий.

Также следует проверять referer источника запроса или, что лучше, сравнивать случайный ключ из переданного от клиента запроса с этим же ключом в куке.

Правило №3. Не доверяйте браузеру

Со стороны сервера всегда относитесь к вашему javascript-коду так, как будто он весь, от первой до последней буквы написан вашим самым ненавистным врагом, желающим сломать ваш сайт, нарушить целостность ваших данных и продать в рабство вашу жену. =)  Тем более, что иногда это действительно так.