Является ли GET или POST более безопасным, чем другой?

При сравнении HTTP GET с HTTP POST, какие различия с точки зрения безопасности? Является ли один из вариантов по своей сути более безопасным, чем другой? Если так, то почему?

Я понимаю, что POST не раскрывает информацию об URL, но есть ли в этом реальная ценность или это просто безопасность через мрак? Есть ли причина, по которой я предпочитаю POST, когда безопасность вызывает беспокойство?

Изменить:
По HTTPS, данные POST кодируются, но могут ли сторонние URL-адреса прослушивать? Кроме того, я имею дело с JSP; при использовании JSP или аналогичной среды, было бы справедливо сказать, что лучше всего избегать помещения конфиденциальных данных в POST или GET в целом и использовать вместо этого код на стороне сервера для обработки конфиденциальной информации?

Что касается безопасности, они по своей сути одинаковы. Хотя это правда, что POST не предоставляет информацию через URL-адрес, он предоставляет столько же информации, сколько GET в реальном сетевом взаимодействии между клиентом и сервером. Если вам нужно передать конфиденциальную информацию, вашей первой защитой будет передача по безопасному HTTP.

Сообщения GET или строки запроса действительно хороши для информации, необходимой либо для закладки определенного элемента, либо для помощи в поисковой оптимизации и индексации элементов.

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

Запрос GET немного менее безопасен, чем запрос POST. Ни один не предлагает истинную «безопасность» сам по себе; использование запросов POST не сделает ваш сайт защищенным от злонамеренных атак на заметную сумму. Однако использование запросов GET может сделать в противном случае безопасное приложение небезопасным.

Мантра о том, что вы «не должны использовать GET-запросы для внесения изменений», все еще очень верна, но это не имеет ничего общего со злонамеренным поведением. Формы входа наиболее чувствительны к отправке с использованием неправильного типа запроса.

Поисковые пауки и веб-ускорители

Это реальная причина, по которой вы должны использовать POST-запросы для изменения данных. Поисковые пауки будут переходить по каждой ссылке на вашем сайте, но не будут отправлять случайные формы, которые они найдут.

Веб-ускорители хуже поисковых пауков, потому что они работают на компьютере клиента и «кликают» по всем ссылкам в контексте вошедшего в систему пользователя . Таким образом, приложение, которое использует GET-запрос для удаления содержимого, даже если для этого требуется администратор, с радостью выполнит указания (не вредоносного!) Веб-ускорителя и удалит все, что увидит .

Запутанная депутатская атака

Запутаться заместитель атаки (где депутат браузер) является возможным , независимо от того, используется ли GET или POST - запрос .

На контролируемых злоумышленниками сайтах GET и POST одинаково легко отправлять без участия пользователя .

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

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

Прокси логи

Прокси-серверы, вероятно, будут регистрировать GET URL-адреса полностью, без удаления строки запроса. Параметры запроса POST обычно не регистрируются. Куки-файлы вряд ли будут зарегистрированы в любом случае. (пример)

Это очень слабый аргумент в пользу POST. Во-первых, незашифрованный трафик может быть зарегистрирован полностью; у вредоносного прокси уже есть все, что нужно. Во-вторых, параметры запроса имеют ограниченное применение для злоумышленника: что им действительно нужно, так это файлы cookie, поэтому, если у них есть только логи прокси, они вряд ли смогут атаковать либо GET, либо POST URL.

Есть одно исключение для запросов на вход в систему: они, как правило, содержат пароль пользователя. Сохранение этого в журнале прокси открывает вектор атаки, который отсутствует в случае POST. Однако вход по обычному HTTP в любом случае небезопасен.

Прокси кеш

Кэширующие прокси могут сохранять ответы GET, но не ответы POST. Тем не менее, ответы GET можно сделать не кэшируемыми с меньшими усилиями, чем преобразование URL-адреса в обработчик POST.

HTTP "Referer"

Если пользователь должен был перейти на сторонний веб-сайт со страницы, обслуживаемой в ответ на запрос GET, этот сторонний веб-сайт получает доступ ко всем параметрам запроса GET.

Относится к категории «показывает параметры запроса третьей стороне», чья серьезность зависит от того, что присутствует в этих параметрах. POST-запросы, естественно, защищены от этого, однако для использования GET-запроса хакеру потребуется вставить ссылку на свой веб-сайт в ответ сервера.

История браузера

Это очень похоже на аргумент «proxy logs»: запросы GET хранятся в истории браузера вместе с их параметрами. Атакующий может легко получить их, если у них есть физический доступ к машине.

Действие обновления браузера

Браузер будет повторять запрос GET, как только пользователь нажмет кнопку «обновить». Это может быть сделано при восстановлении вкладок после завершения работы. Таким образом, любое действие (скажем, платеж) будет повторяться без предупреждения.

Браузер не будет повторять запрос POST без предупреждения.

Это хорошая причина использовать только POST-запросы для изменения данных, но не имеет ничего общего со злонамеренным поведением и, следовательно, с безопасностью.

Так что я должен делать?

• Используйте только POST-запросы для изменения данных, в основном по причинам, не связанным с безопасностью.
• Используйте только POST-запросы для форм входа в систему; в противном случае вводятся векторы атаки.
• Если ваш сайт выполняет конфиденциальные операции, вам действительно нужен кто-то, кто знает, что они делают, потому что это не может быть рассмотрено в одном ответе. Вам нужно использовать HTTPS, HSTS, CSP, смягчить инъекцию SQL, внедрение скриптов (XSS) , CSRF и множество других вещей, которые могут быть специфическими для вашей платформы (например, уязвимость массового назначения в различных средах: ASP.NET MVC , Ruby on Rails и т. Д.). Нет единой вещи, которая будет иметь значение между «безопасным» (не эксплуатируемым) и «не безопасным».

По протоколу HTTPS данные POST кодируются, но могут ли сторонние исследователи прослушивать URL-адреса?

Нет, их нельзя понюхать. Но URL-адреса будут храниться в истории браузера.

Будет ли справедливым сказать, что лучшая практика состоит в том, чтобы избежать возможного помещения конфиденциальных данных в POST или GET в целом и использования кода на стороне сервера для обработки конфиденциальной информации?

Зависит от того, насколько оно чувствительно или, более конкретно, каким образом. Очевидно, клиент увидит это. Любой, кто имеет физический доступ к компьютеру клиента, увидит его. Клиент может подделать его при отправке обратно к вам. Если это имеет значение, тогда да, храните конфиденциальные данные на сервере и не позволяйте им уйти.

У вас нет большей безопасности, потому что переменные отправляются через HTTP POST, чем переменные, отправляемые через HTTP GET.

HTTP / 1.1 предоставляет нам несколько методов для отправки запроса :

• ПАРАМЕТРЫ
• ПОЛУЧИТЬ
• ГЛАВА
• ПОЧТА
• СТАВИТЬ
• УДАЛИТЬ
• TRACE
• CONNECT

Предположим, у вас есть следующий HTML-документ, использующий GET:

<html>
<body>
<form action="http://example.com" method="get">
    User: <input type="text" name="username" /><br/>
    Password: <input type="password" name="password" /><br/>
    <input type="hidden" name="extra" value="lolcatz" />
    <input type="submit"/>
</form>
</body>
</html>

Что спрашивает ваш браузер? Он спрашивает это:

 GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Теперь давайте представим, что мы изменили этот метод запроса на POST:

 POST / HTTP/1.1
 Host: example.com
 Connection: keep-alive
 Content-Length: 49
 Cache-Control: max-age=0
 Origin: null
 Content-Type: application/x-www-form-urlencoded
 Accept: application/xml,application/xhtml+xml,text/ [...truncated]
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

 username=swordfish&password=hunter2&extra=lolcatz

ОБА из этих HTTP-запросов:

• Не зашифрованы
• Включено в оба примера
• Может быть подслушано и подвергаться атакам MITM.
• Легко воспроизводится сторонними и скриптовыми ботами.

Многие браузеры не поддерживают методы HTTP, кроме POST / GET.

Поведение многих браузеров хранит адрес страницы, но это не значит, что вы можете игнорировать любые из этих других проблем.

Итак, чтобы быть конкретным:

Один по своей природе более безопасен, чем другой? Я понимаю, что POST не раскрывает информацию об URL, но есть ли в этом реальная ценность или это просто безопасность через мрак? Какова лучшая практика здесь?

Это правильно, потому что программное обеспечение, которое вы используете для передачи HTTP, имеет тенденцию хранить переменные запроса одним методом, но не другим, только препятствует тому, чтобы кто-то посмотрел историю вашего браузера или какую-то другую наивную атаку от 10-летнего, который думает, что он понимает h4x0r1ng или скрипты, которые проверяют ваш журнал истории. Если у вас есть сценарий, который может проверять ваше хранилище истории, вы также можете легко иметь сценарий, который проверяет ваш сетевой трафик, так что вся эта безопасность через неизвестность лишь обеспечивает скрытность для сценаристов-детишек и ревнивых подруг.

По протоколу https данные POST кодируются, но может ли URL-адрес быть прослушан третьей стороной?

Вот как работает SSL. Помните те два запроса, которые я отправил выше? Вот как они выглядят в SSL: (я изменил страницу на https://encrypted.google.com/, так как example.com не отвечает на SSL).

ПОСТ через SSL

q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r

ПОЛУЧИТЬ через SSL

rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv

(примечание: я преобразовал HEX в ASCII, некоторые из них, очевидно, не должны отображаться)

Весь HTTP-диалог зашифрован, единственная видимая часть связи находится на уровне TCP / IP (имеется в виду IP-адрес и информация о порте соединения).

Итак, позвольте мне сделать большое смелое заявление здесь. Ваш веб-сайт не обеспечен большей безопасностью по одному методу HTTP, чем по другому, хакеры и новички по всему миру точно знают, как делать то, что я только что продемонстрировал здесь. Если вы хотите безопасности, используйте SSL. Браузеры, как правило, хранят историю, в RFC2616 9.1.1 рекомендуется НЕ использовать GET для выполнения действий, но полагать, что POST обеспечивает безопасность, совершенно неверно.

Единственное, что POST является мерой безопасности в отношении? Защита от ревнивого перелистывания истории браузера. Вот и все. Остальной мир вошел в ваш аккаунт, смеясь над вами.

Чтобы еще раз продемонстрировать, почему POST не является безопасным, Facebook использует POST-запросы повсеместно, так как же может существовать такое программное обеспечение, как FireSheep ?

Обратите внимание, что вас могут атаковать с помощью CSRF, даже если вы используете HTTPS и ваш сайт не содержит уязвимостей XSS . Короче говоря, в этом сценарии атаки предполагается, что жертва (пользователь вашего сайта или службы) уже вошла в систему и имеет надлежащий файл cookie, а затем браузер жертвы должен сделать что-то с вашим (предположительно безопасным) сайтом. Если у вас нет защиты от CSRF, злоумышленник может выполнить действия с учетными данными жертвы. Злоумышленник не может увидеть ответ сервера, потому что он будет передан в браузер жертвы, но ущерб обычно уже нанесен в этот момент.

Там нет дополнительной безопасности.

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

Даже если это не POSTдает реального преимущества в плане безопасности по сравнению GETс формами входа в систему или любой другой формой с относительно конфиденциальной информацией, убедитесь, что вы используете POSTкак:

1. Информация POSTed не будет сохранена в истории пользователя.
2. Конфиденциальная информация (пароль и т. Д.), Отправляемая в форме, не будет видна позже в строке URL (при использовании GETона будет отображаться в истории и строке URL).

Также GETимеет теоретический предел данных. POSTне делает.

Для реальной конфиденциальной информации, обязательно используйте SSL ( HTTPS)

Ни один из GET и POST по своей природе не «более безопасен», чем другой, точно так же, как ни один из факсов и телефонов не «более безопасен», чем другой. Предоставляются различные методы HTTP, так что вы можете выбрать тот, который наиболее подходит для решения проблемы, которую вы пытаетесь решить. GET больше подходит для идемпотентных запросов, в то время как POST больше подходит для запросов «действий», но вы можете так же легко попасть в любой из них, если не понимаете архитектуру безопасности для поддерживаемого приложения.

Вероятно, было бы лучше, если бы вы прочитали Главу 9: Определения методов в HTTP / 1.1 RFC, чтобы получить общее представление о том, что GET и POST изначально предполагались, а не означают.

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

Хорошие прокси не будут кэшировать данные POST, но они могут кэшировать данные GET из URL, поэтому вы можете сказать, что POST должен быть более безопасным. Но данные POST по-прежнему будут доступны для прокси, которые не играют хорошо.

Как упоминалось во многих ответах, единственная надежная ставка - через SSL.

Но убедитесь, что методы GET не фиксируют никаких изменений, таких как удаление строк базы данных и т. Д.

Моя обычная методология выбора выглядит примерно так:

• ПОЛУЧИТЬ элементы, которые будут получены позже по URL
  • Например, поиск должен быть GET, чтобы вы могли выполнить search.php? S = XXX позже
• POST для товаров, которые будут отправлены
  • Это относительно невидимо для сопоставления с GET, и его сложнее отправить, но данные все еще можно отправить через cURL.

Это не связано с безопасностью, но ... браузеры не кэшируют POST-запросы .

Ни один из них волшебным образом не обеспечивает безопасность запроса, однако GET подразумевает некоторые побочные эффекты, которые обычно не позволяют обеспечить его безопасность.

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

Однако, просто отправка этих данных не делает их безопасными. Для этого вы хотите SSL. И GET, и POST отправляют данные в виде открытого текста по проводам при использовании по HTTP.

Есть и другие веские причины для данных POST - например, возможность отправлять неограниченное количество данных или скрывать параметры от случайных пользователей.

Недостатком является то, что пользователи не могут добавить в закладки результаты запроса, отправленного через POST. Для этого вам нужно получить.

Рассмотрим следующую ситуацию: неаккуратный API принимает GET-запросы, такие как:

http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1

В некоторых настройках, когда вы запрашиваете этот URL-адрес и появляется сообщение об ошибке / предупреждении, вся эта строка записывается в файл журнала. Что еще хуже: если вы забудете отключить сообщения об ошибках на производственном сервере, эта информация будет просто отображаться в браузере в обычном режиме! Теперь вы только что раздали свой ключ API всем.

К сожалению, есть реальные API, работающие таким образом.

Мне бы не понравилась идея иметь некоторую конфиденциальную информацию в журналах или отображать их в браузере. POST и GET - это не одно и то же. Используйте каждый, где это уместно.

1. БЕЗОПАСНОСТЬ как безопасность данных в пути: нет разницы между POST и GET.

2. БЕЗОПАСНОСТЬ как безопасность данных на компьютере: POST безопаснее (без истории URL)

Понятие безопасности не имеет смысла, если вы не определите, от чего вы хотите быть защищенным.

Если вы хотите быть защищены от сохраненной истории браузера, некоторых типов журналов и людей, просматривающих ваши URL-адреса, тогда POST более безопасен.

Если вы хотите быть в безопасности от того, что кто-то отслеживает вашу сетевую активность, то нет никакой разницы.

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

Сложнее изменить запрос POST (это требует больше усилий, чем редактирование строки запроса). Изменить: Другими словами, это только безопасность по неизвестности, и только это.

Я не собираюсь повторять все остальные ответы, но есть еще один аспект, который я еще не видел, - это история исчезновения данных. Я не знаю, где его найти, но ...

По сути, речь идет о веб-приложении, которое таинственным образом каждую ночь теряет все свои данные, и никто не знает, почему. Изучение журналов позже показало, что сайт был найден Google или другим произвольным пауком, который с радостью ПОЛУЧИЛ (читай: ПОЛУЧИЛ) все ссылки, найденные на сайте, включая «удалить эту запись» и «вы уверены?» ссылки.

На самом деле - часть этого была упомянута. Это история «не меняйте данные на GET, а только на POST». Сканеры будут с радостью следовать GET, а не POST. Даже robots.txt не помогает против плохого поведения сканеров.

Вы также должны знать, что если ваши сайты содержат ссылки на другие внешние сайты, которые вы не контролируете с помощью GET, эти данные будут помещены в заголовок реферера на внешних сайтах, когда они нажимают на ссылки на вашем сайте. Поэтому передача данных для входа в систему с помощью методов GET ВСЕГДА является большой проблемой. Так как это может предоставить учетные данные для легкого доступа, просто проверяя журналы или просматривая аналитику Google (или аналогичную).

RFC7231:

«URI предназначены для совместного использования, а не для защиты, даже когда они идентифицируют защищенные ресурсы. URI часто отображаются на дисплеях, добавляются в шаблоны при печати страницы и хранятся в различных незащищенных списках закладок. Поэтому неразумно включать информация в URI, которая является конфиденциальной, идентифицируемой лично или может быть раскрыта.

Авторам сервисов следует избегать основанных на GET форм для представления конфиденциальных данных, поскольку эти данные будут помещены в целевой запрос. Многие существующие серверы, прокси-серверы и пользовательские агенты регистрируют или отображают целевой запрос в тех местах, где он может быть виден третьим лицам. Такие службы должны использовать вместо этого отправку формы на основе POST. "

В этом RFC четко указано, что конфиденциальные данные не должны предоставляться с использованием GET. Из-за этого замечания некоторые разработчики могут не обрабатывать данные, полученные из части запроса GET-запроса, с той же тщательностью. Я сам работаю над протоколом, который обеспечивает целостность данных. В соответствии с этой спецификацией я не должен был гарантировать целостность данных GET (что я буду делать, потому что никто не придерживается этих спецификаций)

Как ранее говорили некоторые люди, HTTPS обеспечивает безопасность.

Тем не менее, POST немного более безопасен, чем GET, потому что GET может быть сохранен в истории.

Но еще более, к сожалению, иногда выбор POST или GET не до разработчика. Например, гиперссылка всегда отправляется с помощью GET (если она не преобразована в форму публикации с использованием javascript).

GET виден всем (даже тому, кто сейчас у вас на плече) и сохраняется в кеше, поэтому менее безопасно использовать post, кстати, post без какой-либо криптографической подпрограммы не уверен, для некоторой безопасности вы должны использовать SSL ( HTTPS)

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

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

Я не покупаю аргумент «он слишком большой», это не причина, чтобы ничего не регистрировать , по крайней мере, 1 КБ, чтобы люди могли идентифицировать злоумышленников, работающих на слабой точке входа, до тех пор, пока они не выскочат, тогда POST делает двойное отключение, позволяя любому серверу на основе HTTP молча передавать неограниченное количество данных.

Разница в том, что GET отправляет данные открытыми, а POST скрытыми (в http-заголовке).

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

Недавно была опубликована атака , которая позволяет человеку посередине раскрыть тело запроса сжатых HTTPS-запросов. Поскольку заголовки запросов и URL-адреса не сжимаются по протоколу HTTP, запросы GET лучше защищены от этой конкретной атаки.

Существуют режимы, в которых запросы GET также уязвимы, SPDY сжимает заголовки запросов, TLS также обеспечивает необязательное (редко используемое) сжатие. В этих сценариях атаку легче предотвратить (производители браузеров уже предоставили исправления). Сжатие на уровне HTTP является более фундаментальной функцией, и вряд ли производители отключат ее.

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

Отказ от ответственности: Следующие пункты применимы только для вызовов API, а не URL-адресов веб-сайта.

Безопасность в сети : вы должны использовать HTTPS. GET и POST одинаково безопасны в этом случае.

История браузера : для интерфейсных приложений, таких как Angular JS, React JS и т. Д. Вызовы API - это вызовы AJAX, выполняемые интерфейсом. Они не становятся частью истории браузера. Следовательно, POST и GET одинаково безопасны.

Журналы на стороне сервера . С помощью набора записей для маскирования данных и формата журналов доступа можно скрыть все или только конфиденциальные данные из URL-адреса запроса.

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

Следовательно, при правильном ведении журнала GET API так же безопасен, как POST API. Повсеместное соблюдение POST приводит к неправильным определениям API, и его следует избегать.

Почта является наиболее защищенной вместе с установленным протоколом SSL, поскольку она передается в теле сообщения.

Но все эти методы небезопасны, потому что 7-битный протокол, который он использует, поддается взлому. Даже через брандмауэр веб-приложений уровня 4.

Сокеты также не гарантируют ... Хотя это более безопасно в определенных отношениях.

Это старый пост, но я бы хотел возразить против некоторых ответов. Если вы передаете конфиденциальные данные, вы захотите использовать SSL. Если вы используете SSL с параметром GET (например,? Userid = 123), эти данные будут отправлены в виде простого текста! Если вы отправляете с использованием POST, значения помещаются в зашифрованное тело сообщения и, следовательно, не читаются большинством атак MITM.

Большое различие заключается в том, где данные передаются. Имеет смысл только то, что если данные помещены в URL, они НЕ МОГУТ быть зашифрованы, иначе вы не сможете перенаправить на сервер, потому что только вы можете прочитать URL. Вот как работает GET.

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

Даже POST принимает запросы GET. Предположим, у вас есть форма с входными данными, такими как user.name и user.passwd, которые должны поддерживать имя пользователя и пароль. Если мы просто добавим? User.name = "my user & user.passwd =" мой пароль ", то запрос будет принят путем" обхода страницы входа ".

Решением для этого является реализация фильтров (java-фильтров как e) на стороне сервера и обнаружение, что строковые запросы не передаются в качестве аргументов GET.