認証されたユーザーに安らかなクライアントを使用してセキュリティを実装する方法を理解しようとしています。私が問題を抱えているシナリオは、安らかなクライアントが購入 ID を返すため、ユーザーが自分のものではない購入を更新するのを止める方法です。製品 ID は、熟練したユーザーであれば簡単に改ざんできます。httpsを使用することでそれを防止または軽減できるため、私は途中で巻き込まれることにあまり興味がありません. 自分のものではないものを更新しようとしているユーザーに本当に興味があります。
残りの世界でそのような攻撃をどのように防ぎますか? Web パラメータの改ざん
あなたが直面している問題は認可と呼ばれます。ユーザーが認証されると、特定のリソースにアクセスするためのアクセス許可が付与されます。REST シナリオでの承認は、サーバー側で実装する必要があります。
/purchases/1ユーザー Bob が、認証済み (たとえば、基本 HTTP 認証、承認済みセッション Cookie などを使用) の POST 要求をエンドポイント (適切なペイロードで提供) に送信して、購入リソースを変更しようとしたとします。Bob がエンティティの変更を許可されているかどうかを検証するのは、サーバーの義務です (たとえば、実際に購入したのが Bob であるかどうかを確認することによって)。パーミッションが付与されると、サーバーは操作を続行し、2xx 成功 HTTP ステータス コードで応答します。そうしないと、 403エラー コードが返され、ユーザーが特定の購入を変更する権限がないことが通知されます。
認証メカニズムが確立されると、別の問題が発生します。ユーザーが悪意のある入力を投稿して、認証メカニズムをだまして克服しようとします。これは、Web アプリケーション セキュリティの非常に幅広いトピックに関係しています。Web アプリケーションに対する既知の攻撃 (インジェクション攻撃など) は多数あり、それらを防御する方法は他にもあります。アプリケーションのセキュリティ脆弱性をテストすることは、侵入テストと呼ばれます。このようなテストを実行する自動化ツール (およびそのような攻撃を実行する自動化ツール) があることは言及する価値があります。
一般に、非常に幅広いトピックに触れましたが、SOの回答でその100万分の1を説明する方法はありません。この回答を、その地域での独自の調査の出発点として扱ってください。
アプリケーションの状態がサーバーに保存されていない場合、API はステートレスです (リソースの状態とは対照的に)。これら 2 つの違いのわかりやすい説明については、ここをクリックしてください。ステートレス性 (特に認証のコンテキスト) については、多くの議論があります。SOまたはGoogleを参照してください。
一言で言えば、今日の大規模な分散システムを考えると、REST でのステートレス認証は非常に重要です。このような環境でのサーバー側のアプリケーションの状態は、クラスター化された環境で多数のノード間でアプリケーションを共有する場合、スケーラビリティの問題を引き起こす可能性があります。これが、アプリケーションの状態を完全にクライアント側にすることをお勧めする理由です。特に、サーバーがユーザーのアクションを承認する必要があるという私の回答を読んだ後は、最初は混乱するかもしれません。ステートレス認証の実装 (デジタル署名された自己完結型セッション トークン) の例を次に示します。
しかし、恐れる必要はありません。実際には、ほとんどのシステムがアプリケーションの状態の少なくとも一部をサーバーに保存しています (私の知る限り、Google はシステムでこれを行っています)。この回答に記載されているように：
「REST は宗教ではありません (...)。REST の教義は、アプリケーションにとって意味がある限り従う必要があります」