GETまたはPOSTのどちらが他より安全ですか？
HTTP GETとHTTP POSTを比較する場合、セキュリティの観点からの違いは何ですか？選択肢の1つは本質的に他の選択肢より安全ですか？もしそうなら、なぜですか？
POSTはURLの情報を公開しませんが、その中に何か本当の価値があるのか、それとも隠蔽によるセキュリティだけなのかを理解しています。セキュリティが懸念される場合、POSTを優先すべき理由はありますか？
編集：
HTTPS経由でPOSTデータはエンコードされますが、サードパーティによってURLが盗聴される可能性はありますか？さらに、私はJSPを扱っています。 JSPまたは同様のフレームワークを使用する場合、ベストプラクティスは、POSTまたはGETに機密データを配置することを避け、代わりに機密情報を処理するためにサーバー側コードを使用することです。
セキュリティに関しては、本質的に同じです。 POSTがURLを介して情報を公開しないのは事実ですが、クライアントとサーバー間の実際のネットワーク通信では、GETと同じくらい多くの情報を公開します。機密性の高い情報を渡す必要がある場合、最初の防衛線はセキュアHTTPを使用して渡すことです。
GETまたはクエリ文字列の投稿は、特定のアイテムをブックマークするため、または検索エンジンの最適化とアイテムのインデックス作成を支援するために必要な情報に非常に適しています。
POSTは、ワンタイムデータの送信に使用される標準フォームに適しています。 GETを実際のフォームの投稿に使用することはありません。検索フォームで、ユーザーがクエリをブックマークまたはそれらの行に保存できるようにする場合を除きます。
GET要求は、POST要求よりもわずかに安全性が低くなります。どちらも、それ自体では真の「セキュリティ」を提供しません。 POSTリクエストの使用will not魔法のようにWebサイトを悪意のある攻撃から目立った量で保護します。ただし、GETリクエストを使用するとcanそれ以外の場合は安全なアプリケーションが安全でなくなります。
「GETリクエストを使用して変更を加えてはならない」というマントラは依然として非常に有効ですが、これはmaliciousの動作とはほとんど関係ありません。ログインフォームは、間違ったリクエストタイプを使用して送信されることに最も敏感なものです。
検索スパイダーとWebアクセラレーター
これが、データを変更するためにPOST要求を使用する必要がある本当の理由です。検索スパイダーはWebサイト上のすべてのリンクをたどりますが、見つけたランダムなフォームは送信しません。
Webアクセラレータは、クライアントのマシン上で実行され、すべてのリンクを「クリック」するため、検索スパイダーよりも劣りますログインしているユーザーのコンテキストで。したがって、GETリクエストを使用してものを削除するアプリケーションは、管理者が必要な場合でも、（悪意のない！）Webアクセラレータの命令に従い、 表示されているものをすべて削除します 。
混乱した代理攻撃
混乱した代理攻撃 （代理がブラウザである場合）は、GETまたはPOST要求を使用するかどうかに関係なく 可能です 。
攻撃者が制御するWebサイトでは、GETおよびPOSTは ユーザーによる操作なしで簡単に送信 できます。
POSTの影響がやや少ない唯一のシナリオは、攻撃者の制御下にない多くのWebサイト（サードパーティのフォーラムなど）が任意の画像を埋め込むことを許可することです（攻撃者が任意のGETリクエストを挿入できるようにする）ただし、自動または手動にかかわらず、任意のPOSTリクエストを注入するすべての方法を禁止します。
ウェブアクセラレータは混乱した代理攻撃の例であると主張するかもしれませんが、それは定義の問題です。どちらかといえば、悪意のある攻撃者はこれを制御できないため、代理のisが混乱していても、ほとんどattackにはなりません。
プロキシログ
プロキシサーバーは、クエリ文字列を削除せずに、GET URL全体をログに記録する可能性があります。 POST要求パラメーターは通常記録されません。いずれの場合もCookieが記録されることはほとんどありません。 （例）
これは、POSTを支持する非常に弱い議論です。第一に、暗号化されていないトラフィック全体をログに記録できます。悪意のあるプロキシには必要なものがすべて揃っています。第二に、リクエストパラメータは攻撃者に限定的に使用されます。本当に必要なのはCookieであるため、プロキシログのみを持っている場合、GETまたはPOSTのいずれかを攻撃できる可能性は低いです。 URL。
ログインリクエストには1つの例外があります。これらには、ユーザーのパスワードが含まれる傾向があります。これをプロキシログに保存すると、POSTの場合には存在しない攻撃のベクトルが開きます。ただし、プレーンHTTPを介したログインは本質的に安全ではありません。
プロキシキャッシュ
キャッシュプロキシはGET応答を保持しますが、POST応答は保持しない場合があります。そうは言っても、GET応答は、URLをPOSTハンドラーに変換するよりも少ない労力でキャッシュ不可にできます。
HTTP「リファラー」
ユーザーがGETリクエストへの応答で提供されるページからサードパーティのWebサイトに移動した場合、そのサードパーティのWebサイトはすべてのGETリクエストパラメータを見ることができます。
「要求パラメーターを第三者に明らかにする」というカテゴリーに属し、その重大度はそれらのパラメーターに存在するものに依存します。 POSTリクエストは自然にこれに影響されませんが、ハッカーがGETリクエストを悪用するには、自分のWebサイトへのリンクをサーバーの応答に挿入する必要があります。
ブラウザ履歴
これは、「プロキシログ」引数に非常に似ています。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はリクエストを送信するための多くのメソッドを提供します ：
- オプション
- GET
- HEAD
- POST
- プット
- 削除
- トレース
- 接続する
GETを使用して次のHTMLドキュメントがあるとします。
<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攻撃を受ける可能性があります。
- サードパーティおよびスクリプトボットによって簡単に再現できます。
多くのブラウザーは、POST/GET以外のHTTPメソッドをサポートしていません。
多くのブラウザー動作はページアドレスを格納しますが、これはこれらの他の問題を無視できるという意味ではありません。
具体的には：
本質的に別のものよりも安全ですか？ POSTはURLの情報を公開しませんが、その中に何か本当の価値があるのか、それとも不明瞭さによるセキュリティだけなのかを理解しています。ここでのベストプラクティスは何ですか？
HTTPを話すために使用しているソフトウェアは、リクエスト変数を1つの方法で保存する傾向がありますが、別の方法ではなく、ブラウザーの履歴や、h4x0r1ngを理解していると考える10歳のその他の素朴な攻撃を誰かが見るのを防ぐことができます、または履歴ストアを確認するスクリプト。履歴ストアをチェックできるスクリプトがある場合は、ネットワークトラフィックをチェックするスクリプトを簡単に作成できます。そのため、このセキュリティ全体の不明瞭さは、スクリプトキディやje深いガールフレンドに不明瞭さを与えるだけです。
Httpsでは、POSTデータはエンコードされますが、サードパーティがURLを盗聴する可能性はありますか？
SSLの仕組みは次のとおりです。上記で送信した2つのリクエストを覚えていますか？ SSLでの表示は次のとおりです（example.comがSSLで応答しないため、ページを https://encrypted.google.com/ に変更しました）。
SSL経由のPOST
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を介したGET
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
（注：16進数をASCIIに変換しましたが、一部は明らかに表示できないはずです）
HTTP会話全体が暗号化され、通信の目に見える部分はTCP/IP層上のみです（IPアドレスと接続ポート情報を意味します）。
そこで、ここで大胆な発言をさせてください。あなたのWebサイトは、あるHTTPメソッドよりも別のHTTPメソッドよりも優れたセキュリティを提供していません。世界中のハッカーや初心者は、ここで説明したことを正確に行う方法を知っています。セキュリティが必要な場合は、SSLを使用してください。ブラウザは履歴を保存する傾向があるため、RFC2616 9.1.1ではGETを使用してアクションを実行しないことを推奨していますが、POSTがセキュリティを提供すると考えることはまったく間違っています。
POSTが唯一のセキュリティ対策は何ですか？ブラウザの履歴をめくるexの元に対する保護。それでおしまい。残りの世界はあなたのアカウントにログインしてあなたを笑っています。
POSTが安全でない理由をさらに実証するために、FacebookはPOSTリクエストをあらゆる場所で使用しているため、 FireSheep などのソフトウェアは存在する？
HTTPSを使用し、サイトに XSS 脆弱性が含まれていない場合でも、 CSRF で攻撃される可能性があることに注意してください。要するに、この攻撃シナリオでは、被害者（サイトまたはサービスのユーザー）がすでにログインしており、適切なCookieを持っていると想定し、被害者のブラウザーは（おそらく安全な）サイトで何かをするように要求されます。 CSRFに対する保護がない場合、攻撃者は被害者の資格情報でアクションを実行できます。サーバーの応答は被害者のブラウザに転送されるため、攻撃者はサーバーの応答を確認できませんが、通常、その時点で被害はすでに発生しています。
追加のセキュリティはありません。
投稿データは履歴ファイルやログファイルに表示されませんが、データを保護する必要がある場合はSSLが必要です。
それ以外の場合、ワイヤを盗聴する人は誰でもあなたのデータを読むことができます。
POSTがGETに対して実際のセキュリティ上の利点を与えない場合でも、ログインフォームまたは比較的機密性の高い情報を含む他のフォームの場合は、必ずPOSTを次のように使用してください。
- 情報
POSTedは、ユーザーの履歴には保存されません。 - フォームで送信された機密情報（パスワードなど）は、後でURLバーに表示されません（
GETを使用すると、履歴とURLバーに表示されます）。
また、GETにはデータの理論的な制限があります。 POSTはしません。
実際の機密情報については、必ずSSL（HTTPS）を使用してください
GETとPOSTのどちらも、FAXと電話のどちらも他方よりも「安全」であるように、本質的に他方よりも「安全」ではありません。さまざまなHTTPメソッドが提供されているため、解決しようとしている問題に最も適したものを選択できます。 GETは idempotent クエリに適していますが、POSTは "アクション"クエリに適していますが、そうでない場合でも簡単に自分の足で撃つことができます。メンテナンスしているアプリケーションのセキュリティアーキテクチャを理解していない。
第9章：メソッド定義 の HTTP/1.1 RFC を読んで、GETおよびPOSTが最初に想定されていたものの全体像を把握するのが最善です。意味します。
GETとPOSTの違いは、セキュリティの観点からではなく、サーバーに対する意図で見るべきです。 GETは、サーバー上のデータを変更することはありません-少なくともログ以外では-しかし、POSTは新しいリソースを作成できます。
ナイスプロキシはPOSTデータをキャッシュしませんが、URLからGETデータをキャッシュする可能性があるため、POSTはより安全であると言えます。ただし、POSTデータは、正常に再生されないプロキシでも引き続き使用できます。
多くの回答で述べたように、唯一の確実な賭けはSSL経由です。
ただし、GETメソッドがデータベース行の削除などの変更をコミットしないようにしてください。
これはセキュリティ関連ではありませんが... ブラウザはPOSTリクエストをキャッシュしません。
私の通常の選択方法は次のようなものです。
- GETになるアイテムの場合取得済み後でURL
- 例えば。あとでsearch.php？s = XXXを実行できるように、検索はGETである必要があります
- POSTになるアイテムの場合sent
- これは相対的なGETに不可視で送信が困難ですが、データはcURLを介して送信できます。
どちらも魔法のようにリクエストにセキュリティを付与するわけではありませんが、GETは、一般的に安全性を妨げるいくつかの副作用を意味します。
GET URLは、ブラウザーの履歴とWebサーバーのログに表示されます。このため、ログインフォームやクレジットカード番号などには使用しないでください。
ただし、そのデータをPOSTするだけでは、安全ではありません。そのためには、SSLが必要です。 GETとPOSTの両方は、HTTP経由で使用される場合、データをプレーンテキストで送信します。
POSTデータには、他にも十分な理由があります。たとえば、無制限の量のデータを送信したり、一般ユーザーからパラメーターを隠したりすることができます。
欠点は、ユーザーがPOST経由で送信されたクエリの結果をブックマークできないことです。そのためには、GETが必要です。
この状況を考慮してください：ずさんなAPIは次のようなGETリクエストを受け入れます：
http://www.example.com/api?apikey=abcdef123456&action=deleteCategory&id=1
いくつかの設定では、このURLをリクエストし、リクエストに関するエラー/警告がある場合、この行全体がログファイルに記録されます。さらに悪いことに、実稼働サーバーでエラーメッセージを無効にするのを忘れた場合、この情報はブラウザーにそのまま表示されます。これで、APIキーをすべての人に渡すことができました。
残念ながら、この方法で動作する実際のAPIがあります。
ログに機密情報を含めたり、ブラウザに表示したりすることは好ましくありません。 POSTとGETは同じではありません。必要に応じてそれぞれを使用します。
転送中のデータの安全性としてのセキュリティ：POSTとGETの間に違いはありません。
コンピューター上のデータの安全性としてのセキュリティ：POSTはより安全です（URL履歴はありません）
セキュリティの概念は、何に対してセキュリティを確保したいかを定義しない限り、意味がありません。
保存されたブラウザの履歴、一部の種類のログ、URLを見ている人に対して安全にしたい場合は、POSTの方が安全です。
誰かがあなたのネットワークアクティビティを盗聴するのを防ぎたい場合、違いはありません。
また、GETを使用して制御できない他の外部サイトへのリンクがサイトに含まれている場合、サイトのリンクを押したときに、外部サイトの参照ヘッダーにそのデータが格納されることに注意する必要があります。そのため、GETメソッドを使用してログインデータを転送することは常に大きな問題です。そのため、ログを確認するか、Googleアナリティクス（または同様のもの）を調べるだけで簡単にアクセスできるようにログイン資格情報が公開される可能性があるためです。
POSTリクエストを変更することは困難です（クエリ文字列を編集するよりも手間がかかります）。 編集：言い換えれば、それはあいまいさによるセキュリティのみであり、それはほとんどありません。
多くの人は、GET要求はデータを取得するだけで、サーバー上のデータを変更せず、POST要求がすべてのデータ変更に使用されるという規則を採用しています（Rossに除外）。一方が他方よりも本質的に安全ではありませんが、doこの規則に従うと、横断的なセキュリティロジックを適用できます（たとえば、アカウントを持っている人だけがデータを変更できるため、認証されていないPOSTは拒否されます）。
以前に一部の人が言ったように、HTTPSはセキュリティをもたらします。
ただし、POSTはGETよりも安全です。これは、GETを履歴に保存できるためです。
しかし、悲しいことに、POSTまたはGETの選択が開発者次第ではない場合もあります。たとえば、ハイパーリンクは常にGETによって送信されます（javascriptを使用して投稿フォームに変換されない限り）。
私は他のすべての答えを繰り返すつもりはありませんが、私がまだ言及していない1つの側面があります-それは消えるデータの物語です。どこにあるかわかりませんが...
基本的には、数晩毎に不思議なことにすべてのデータが失われ、誰もその理由を知らなかったWebアプリケーションについてです。ログを調べると、サイトがグーグルや他の任意のスパイダーによって発見されたことが明らかになり、サイト上で見つかったすべてのリンクを「GET this（read：GOT）」-「このエントリを削除」や「よろしいですか？」リンク。
実際には、この一部が言及されています。これが「GETではデータを変更せず、POSTでのみデータを変更する」ことの背後にあるストーリーです。クローラーはGETを喜んでフォローし、POSTはしません。 robots.txtでさえ、クローラーの誤動作を防ぐことはできません。
RFC7231：
「URIは、安全なリソースを識別する場合でも、安全ではなく共有することを目的としています。URIは多くの場合、ディスプレイに表示され、ページの印刷時にテンプレートに追加され、さまざまな保護されていないブックマークリストに保存されます。したがって、含めることは賢明ではありません機密情報、個人を特定できる情報、または開示のリスクがあるURI内の情報。
サービスの作成者は、機密データを送信するためのGETベースのフォームは避ける必要があります。そのデータはリクエストターゲットに配置されるためです。多くの既存のサーバー、プロキシ、およびユーザーエージェントは、サードパーティに表示される可能性のある場所にリクエストターゲットを記録または表示します。そのようなサービスは、代わりにPOSTベースのフォーム送信を使用する必要があります。」
このRFCは、GETを使用して機密データを送信しないことを明記しています。この発言により、一部の実装者は、GETリクエストのクエリ部分から取得したデータを同じ注意で処理しない場合があります。私は自分でデータの整合性を保証するプロトコルに取り組んでいます。この仕様によると、GETデータの整合性を保証する必要はありません（これらの仕様に誰も従わないため、これは保証します）
GETは誰でも（現在肩にあるものでも）に表示され、キャッシュに保存されるため、postを使用するのは安全性が低く、暗号化ルーチンなしでpostを使用するのは確実ではありません。 https）
最近、 攻撃 が公開されました。これにより、中間の人間が圧縮されたHTTPS要求の要求本文を明らかにすることができます。要求ヘッダーとURLはHTTPで圧縮されないため、GET要求はこの特定の攻撃に対してより安全に保護されます。
モードがあります GETリクエストも脆弱であり、SPDYはリクエストヘッダーを圧縮し、TLSはオプションの（まれに使用される）圧縮も提供します。これらのシナリオでは、攻撃を簡単に防ぐことができます（ブラウザーベンダーは既に修正プログラムを提供しています）。 HTTPレベルの圧縮はより基本的な機能であり、ベンダーがそれを無効にすることはほとんどありません。
これは、GETがPOSTよりも安全なシナリオを示す単なる例ですが、この攻撃理由からPOSTよりもGETを選択することは良い考えではないと思います。攻撃は非常に高度であり、重要な前提条件が必要です（攻撃者は要求コンテンツの一部を制御できる必要があります）。攻撃が有害となるシナリオでは、HTTP圧縮を無効にすることをお勧めします。
1つの理由POSTがセキュリティ上悪いのは、GETがデフォルトでログに記録されることです。パラメータとすべてのデータはほとんどすべてのWebサーバーによって記録されます。
POST はoppositeであり、ほぼ例外なくログに記録されないで、攻撃者の活動を見つけるのは非常に困難です。
私は「大きすぎる」という議論を買いません。それは、少なくとも1KBのログanythingをしない理由ではありません。エントリポイントがポップされるまで、POSTは、HTTPベースのバックドアが無制限に無制限のデータ量を渡すことを可能にすることにより、二重のサービスを行います。
免責事項：次の点は、API呼び出しにのみ適用され、WebサイトのURLには適用されません。
ネットワーク上のセキュリティ：HTTPSを使用する必要があります。この場合、GETとPOSTは等しく安全です。
ブラウザ履歴：Angular JS、React JSなどのフロントエンドアプリケーションの場合、API呼び出しはAJAX呼び出しです。終わり。これらはブラウザの履歴の一部にはなりません。したがって、POSTとGETは等しく安全です。
サーバー側のログ：データマスキングとアクセスログのフォーマットの書き込みセットを使用すると、リクエストURLからすべてまたは機密データのみを非表示にできます。
ブラウザコンソールでのデータの可視性：悪意のあるユーザーにとって、POSTデータをGETと同じくらい表示するのはほとんど同じ努力です。
したがって、適切なロギングプラクティスにより、GET APIはPOST APIと同じくらい安全です。どこでもPOSTに従って、貧弱なAPI定義を強制するため、避ける必要があります。
違いは、GETはデータを開いて送信し、POSTは非表示（httpヘッダー内）で送信することです。
したがって、getは、Googleのクエリ文字列のような安全でないデータには適しています。認証データはGETを介して送信されないため、ここでPOSTを使用します。もちろん、全体のテーマはもう少し複雑です。さらに読みたい場合は、 この記事 （ドイツ語）をお読みください。