Comments 4
Всегда нужно выставлять вот такие флаги:
Secure
HTTPOnly
Классическая (и рабочая везде) защита от XSRF основана как раз на чтении движком скриптовым cookie, но вы это сломаете. Подобная модель, например, используется в angular, в js либе axios, да и почти всюду (в довесок к новомодным хедерам)…
Access-Control-Allow-Origin похож на какое-то магическое заклинание, котороое на самом деле не защищает ни от чего. Что мешает свормировать HTTP запрос с «правильным» Origin?
это о браузере речь — браузер перед тем как сделать запрос (речь о js через fetch/XMLHttpRequest, не о, например img теге) с домена ХХХ на домен YYY сделает OPTIONS запрос на YYY и, если не увидит в ответе Access-Control-Allow-Origin с доменом ХХХ (ну или звездочку), то и запрос реальный делать не станет.
Руками-то собрать любой HTTP запрос и дёрнуть его не в браузере (curl например) труда не составляет, тут все упирается в браузер и его безопасность.
Например: Защищает стало быть от угона обычно токенов безопасности (того же httpOnly cookie) на чужой домен, когда сайтец выломали (на клиенте) и пытаются сделать из браузера запрос на свой домен. Проще говоря это позволяет установить доверительные отношения между от «домена-сайта» до «домена api».
Руками-то собрать любой HTTP запрос и дёрнуть его не в браузере (curl например) труда не составляет, тут все упирается в браузер и его безопасность.
Например: Защищает стало быть от угона обычно токенов безопасности (того же httpOnly cookie) на чужой домен, когда сайтец выломали (на клиенте) и пытаются сделать из браузера запрос на свой домен. Проще говоря это позволяет установить доверительные отношения между от «домена-сайта» до «домена api».
Лучше пойти убится, чем писать такие статьи. Заголовок не отображает содержимого. Обзор 3х HTTP Headers высосан из пальца, а такое громкое название: «Полное руководство ..».
Sign up to leave a comment.
Полное руководство по настройке HTTP-заголовков для безопасности