Почему браузеры позволяют устанавливать некоторые заголовки без CORS, но не другие? Пытаясь избежать предполетных перелетов

Question

Я пытаюсь избежать 0 предварительных запросов CORS для авторизованных запросов GET по причинам задержки. Простой способ сделать это - вставить токен доступа в параметр запроса URL, но это плохая практика безопасности 1 .

Согласно этому ответу 2 , цель браузеров - блокировать все, что не может быть достигнуто с помощью тегов HTML, таких как img или script. Но если это так, то почему разрешено устанавливать заголовки как Accept или Content-Langage? Вы не можете установить их на тег img. Кроме того, что мешает мне скрыть свой токен доступа в заголовке Accept следующим образом:

Accept: */*, x-access-token/<access_token>

Кажется, что политики браузера в этом случае не добавляют дополнительную защиту, и поощрять разработчиков использовать небезопасные методы или неприятные хаки. Чего мне не хватает?

Answer 1

В чем вопрос?

К вашему сведению: на самом деле у вас нет единственного вопроса, на который можно ответить. У вас есть, например, миллион.

Ваш заголовок задает довольно философский вопрос без ответа, но ваш пост просит найти решение для варианта использования.

Почему браузеры Разрешить устанавливать некоторые заголовки без CORS, но не другие?

Персональный / командный уклон. Политика. Религия.

Кажется, что политики браузера в этом случае не добавляют дополнительную защиту и побуждают разработчиков использовать небезопасные методы или неприятные хаки. Чего мне не хватает?

Это называется «Театр безопасности».

Это когда люди, которые знают лучше, делают политический выбор, который кажется таким легким (или таким трудным) для понимания тем, кто не обладает знаниями для понимания таких вещей (или не обязан их реализовывать), просто примите это, чтобы они могли продолжить свою жизнь - или в случае Verisign, VPN и других - чтобы получить прибыль.

почему разрешено устанавливать заголовки, такие как Accept или Content-Langage?

Это доброкачественные заголовки, которые не содержат ничего особенно идентифицируемого или чувствительного

Попытка избежать предварительных полетов с токенами доступа

Простой способ сделать это - вставить токен доступа в параметр запроса URL, но это плохая практика безопасности.

Да и нет.

Если это токен сеанса и он длится 90 дней ... конечно, есть некоторые недостатки ... при условии, что вы либо не используете https ( что плохо) или • злоумышленник уже имеет доступ к компьютеру пользователя (через код или иным образом) ... в этом случае злоумышленник имеет доступ к своей электронной почте, чтобы сбросить все свои пароли и логины и, возможно, свой MFA (т.е. iMessage / Authy / LastPass), а также ... meh

Если это недолговечный («короткий», скажем, 15-минутный) токен для нечувствительных данных (т. е. мусор в социальных сетях), кого это волнует ?

Вы также можете сделать одноразовый токен , который, если вы не поместите конфиденциальную информацию в сам токен, сделает всех счастливыми.

Грязные мысли

Рассматривали ли вы создание единой конечной точки, которая может прокси-запросы? Это то, что все дети делают в эти дни (глядя на вас GraphQL).

И если вы приложите достаточно усилий, iframes всегда найдет способ оскорбить вашу проблему. Это WD-40 (или клейкая лента) в Интернете. Найдите свои чувства ... вы знаете, что это правда.