Как обезопасить GET-запрос при запросе на вкладке браузера

Question

В настоящее время я занимаюсь разработкой API данных фондового рынка, где безопасность превыше всего. Мне удалось защитить входящие GET-запросы, используя JWT, ключи API, авторизацию промежуточного программного обеспечения.

Допустим, когда пользователь не вошел в систему, как мы все знаем, все методы http, esp GET, отвечают с помощью статуса http 401 неавторизованным доступом.

Моя проблема в том, что когда пользователь вошел в наше приложение, запросы API теперь могут быть успешно обработаны (сервер-сервер), но , когда я копирую ссылку запроса на новую вкладку браузера (скажем, Chrome). ), Я вижу ответ . Ожидается, так как пользователь вошел в систему, но я хочу, чтобы ответ на запрос не был виден в браузере. Другие наши конкуренты используют POST, чтобы противостоять браузеру GET default.

Должны ли мы перейти на POST? Я изо всех сил, так как GET - правильный HTTP-метод для запроса материалов.

Answer 1

Для личных вещей, таких как данные фондового рынка, моим первым выбором был бы пост-запрос.

Однажды я заблокировал GET API-запрос от браузеров, обнаружив браузер, основываясь на таких вещах, как строка useragent,и собственные метаданные головы, но, исходя из опыта, это не идеальное решение.

Еще один прием, который я использовал в прошлом, заключался в использовании простого алгоритма шифрования (он не был безопасным, но быстрым. Это было просто отвлечение внимания) для шифрования значений. Поэтому, если кто-то извлечет ответ json, данные будут мусорными, если они не будут расшифрованы с помощью ключа, который может быть токеном jwt в вашем случае. будет достаточно отвлечения для регулярных и средних обратных приемов. Также отказ от ответственности, я никогда не использовал GET для чего-то важного в качестве финансовой информации и информации, связанной с акциями. Моим правилом было GET для обычного наполнителя и POST для важного.

Answer 2

Рекомендуется перейти на POST, если вы хотите скрыть вывод в окне браузера. Как и в случае GET, браузер всегда будет отображать вывод напрямую.

Однако учтите, что если кто-то хочет увидеть ответ API, он все равно может имитировать вызовы API с помощью JS и увидеть ответ в консоли браузера или использовать клиент, такой как Postman, для получения ответа. Если у них есть надлежащие токены, они всегда могут проверить ваш ответ, и нет никакого способа обойти это.

Я полагаю, что это работает и в новой вкладке, потому что пользователь вошел в систему и токен JWT хранится в cookie / localstorage / таким образом, который доступен из новых вкладок. И ваш сервер также может получить к нему доступ.

Если вы отправляете токен с помощью приложения JS (может быть React?) И настраиваете свой сервер так, чтобы каждый раз принимать токен через заголовок запроса, в этом случае простое открытие этого URL больше не будет работать, посколькубудет отсутствовать токен в заголовке запроса.