Комментарии 19
Чё-то я ваще не согласен. Статья какого-то страшно разгневанного нерда у которого интернет не работает так как ему нравится.
"Соответственно, скрипт может выполнить POST https://your-bank.example/transfer?to=fungames&amount=1000000000 и переправить миллиард долларов на счёт своего хозяина." - нет не выполнит. любой браузер сначала отправит чистый OPTIONS вообще без всяких авторизаций, и если не получит в ответ CORS политику разрешающую и запрос и отправку куки - ни пса он не выполнит.
"Один из лучших способов в принципе избежать такой проблемы – это отказаться от использования неявных учётных данных." - нифига мне не нравится такой вариант. в таком варианте токен авторизации будет где-то болтаться посреди javascript, где-то его можно будет прочитать из payload и так далее. тогда как cookie можно поставить httponly, и она будет в принципе недоступна javascript. авторизация будет разделена от функциональности и выковыривать её если что надо будет из другого места, если уж удалось заинжектить клиенту вредоносный скрипт.
"Наилучшее решение — настроить на стороне сервера промежуточное ПО таким образом, чтобы оно игнорировало неявные учётные данные при всех межсайтовых запросов." - так можно было бы их вообще запретить в браузере и дело с концом! раз кому-то они так не нравятся. но дело-то в том что они как раз нужны в сложных системах. например есть веб морда какого-то сложного сервиса, который тянет API с нескольких микросервисов, не имеет своего состояния, и использует как раз запросы на микросервисы по другим URL. и вот тут-то всё это склеивается нормально настроеной CORS политикой. для чего она собственно и сделана и в контексте чего отлично работает и все её опции и методы работы понятны. независимо от того что некоторых операторов локалхоста эти все "ненужные" сложности бесят.
О да, мне было лень все это расписывать, когда прочитал это статью, вернулся, чтобы проверить, нашлись ли добрые люди)
ну видит JS токен авторизации. А минусы где?
Меня как пользователя бесит как сам концепт кросс-доменных куки (какого черта левый сайт может сделать запрос с сенсетив информацией), так и окна согласия на куки, которые не дают пользоваться вебом.
Спасибо за статью.
Не могу понять, почему поголовно не делают фронтенд-прокси на том же домене что и фронтенд, работающий по strict-origin без CORS только для этого фронтенда. Можно не бояться xsrf, не беспокоиться о правильной настройке CORS (в вашем примере не хватает allow-headers, которые часто нужны). И options запросов нет, которые так мешают фронтендерам.
А рядом если надо еще апишку для external клиентов с CORS но без cookie авторизации.
Так делают... Это самое простое решение к которому склоняются все, когда встаёт выбор - разобраться с такой довольно сложной вещью как CORS, поставить Allow: *, сделать всё на том же хосте с прокси к сервисам. Чаще всего опыта чтобы отбросить уровень 0 (поставить Allow: *) уже хватает, а вот количество усилий нужное на качественный скачок до уровня 2 - сделать CORS по уму, по сравнению с уровнем 1 - сбацать всё на прокси кажется просто непропорциональным.
И я честно даже не буду играть в сноба от того что я разобрался с CORS, можно и на прокси. Действительно реальных технических плюсов выделяющий тот или иной подход - нет. Кроме того что прокси понятней и проще.
Тут кстати очень характерна недавняя история с Google Chrome который собрался депрекейтить cross-site cookie в ноль, так чтобы они вообще не работали в браузере. У них так и было написано в дисклеймере, если вам реально нужно передавать авторизацию на сторонние сайты - делайте прокси через тот сайт с которым вы работаете. То есть даже большие корпорации "делающие" наш интернет вполне адекватно оценивают сложности того или иного подхода. Но всё же дело закончилось тем, что они отменили своё решение, и cross-site cookie продолжат работу, потому что видимо всё же нашлись реальные большие кейсы когда такой подход - верный. И мне кажется чтобы переубедить гугл нужны веские аргументы что вот такой подход (в этом случае часть CORS, даже не весь, о похоронах CORS как жаждет автор статьи речь даже не шла) - необходимая технология.
Интересно, есть ли разница в производительности, по идее OPTIONS тоже не бесплатный
ну он отправляется один раз и кэшируется на сколько скажешь в ответе... обычно API довольно ограниченное количество, OPTIONS ко всему что используется на странице пролетит мгновенно по мере надобности и будет запомнен для всех последующих запросов.
да, есть какие-то накладные расходы, но в вебе разница в 50 миллисекунд это... ну камон... у меня эта статья сейчас открывалась примерно полторы секунды пока всё догрузила...
И мне кажется чтобы переубедить гугл нужны веские аргументы
Фича не взлетела по очень простой причине - у кучи пользователей сломались их сайты, им начали говорить чтобы сносили гугл хром, ставили Firefox/edge. Доля браузера начала уменьшать - продакты стали переживать - фичу откатили.
Жду статью о пользе встраивания в iframe сторонних сайтов без явных на то разрешений.
Если пофантазировать, то правильное решение отказаться от поддержки кук браузером и сайтами вообще (за одно похоронить куки-банеры), и всем перейти на bearer jwt auth.
Нужно уже сейчас покрасить куки как obsolete, и потом, когда-нибудь, отключить эту функцию в браузерах.
Явное лучше неявного.
Натыкался тут на новости, что хром собирался внедрить проверку на уровни сетей, а ля 192.168.*.*, 10.*.*.*, и прочие внешние и внутренние. И вот если запрос (получается междоменный) в разные ранги сетей, то он не пропускается. Вроде только на 127.0.0.1 из всех сетей пускает. Кто то слышал об этой фиче? Есть по ней новости?
По умолчанию в соответствии с такой политикой можно делать запросы, но нельзя читать результаты.
А ни как иначе same-origin policy и не должна работать. Это просто универсальный механизм, который запрещает доступ к ресурсу на домене Х со стороны скрипта с домена Y. И речь не только о фетч-зхапросах - невозможность прочитать куки с другого домена, заглянуть внутрь ифрейма с другого домена или даже посмотреть содержимое загруженной с другого домена картинки - это все то самое same-origin policy.
Помните, CORS – не для блокирования доступа, а для того, чтобы нельзя было случайно переиспользовать неявные учётные данные.
А я думал чтобы как раз таки было можно. Без CORS все запрещено, а при включении CORS - немножечко можно.
Ну да, это же так сложно принять на бэке option запрос, проверить домен и отдать для него правила CORS, и затем повториить этуже валидаю для get/post etc запросов. Эти правила помогают при работе с неограниченным кол-вом поддоменов и в целом доменов, возьмите как пример констуркторы сайтов.
Еще есть CSRF токен - https://stackoverflow.com/questions/5207160/what-is-a-csrf-token-what-is-its-importance-and-how-does-it-work, которому CORS помогает.
CORS — это тупо