ユーザーの意図的な不正行為を考慮した場合、私はオーバーエンジニアリングしますか？

ユーザーが意図した不正行為（軽度に言えば）に対する保護を追加すると、ユーザーが被る可能性のある害がコードに関連していない場合、過剰なエンジニアリングになりますか？

明確にするために、次のような単純なJSON RESTfulサービスを公開しています。

GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item

サービス自体はブラウザで使用するためのものではなく、ユーザーが制御するサードパーティ製アプリケーション（電話アプリ、デスクトップアプリなど）からのみ使用するものです。また、サービス自体はステートレス（つまり、セッションレス）でなければなりません。

認証は、SSL経由の基本認証で行われます。

私は、次のような1つの可能な「有害な」動作について話しています。

ユーザーはブラウザにGET URLを入力します（理由はありませんが...）。ブラウザは基本認証を要求し、それを処理し、現在のブラウジングセッションの認証を保存します。ブラウザを閉じずに、ユーザーは悪意のあるWebサイトにアクセスします。このWebサイトには、サービスへのPOSTを作成する悪意のあるCSRF / XSRF javascriptがあります。

上記のシナリオは非常にまれであり、ビジネスの観点からはあまり心配するべきではないことを知っています。しかし、状況を改善するために、JSON POSTデータでもユーザー名/パスワードが必要な場合に役立つと思いますか？

または、基本認証を完全に削除し、GETを削除して、認証情報を含むPOST / PUTのみを使用する必要がありますか？GETを介して取得された情報は機密性が高い場合もあります。

一方、カスタムヘッダーの使用は純粋なREST実装と見なされますか？基本認証を削除し、カスタムヘッダーを使用できます。そうすれば、少なくともブラウザーからのCSRF攻撃を回避でき、サービスを使用するアプリケーションはカスタムヘザーでユーザー名/パスワードを設定します。このアプローチの欠点は、ブラウザからサービスを使用できないことです。

オーバーエンジニアリング？どういたしまして。アンチXSRF対策は、安全なWebアプリケーションまたはサービスの必要な部分です。誰かがあなたを攻撃することを選択する可能性は「非常に低い」場合もそうでない場合もありますが、それによってソフトウェアの安全性が低下することはありません。

システムは一般にXSRFを使用して攻撃されており、結果はSQLインジェクションまたはXSSよりすぐに明らかに悪いものではありませんが、ユーザーが操作可能なすべての機能を損なうほどひどいものです。

つまり、呼び出し自体のプロパティのみがパラメーターである「純粋な」RESTfulインターフェースを使用できないということです。攻撃者が推測できないものをリクエストに含める必要があります。それはユーザー名とパスワードのペアかもしれませんが、それは唯一の可能な選択からはほど遠いです。パスワードのソルトハッシュから生成されたトークンと一緒にユーザー名を持つことができます。認証時にサービス自体が発行したトークンを使用できます（セッションで記憶したり、暗号で検証したりできます）。

GETを取り除く必要があります

いいえ、GET要求は、アクティブな書き込み操作のない読み取り要求に使用されます（それらは「べき等」です）。XSRF保護を必要とするのは書き込み操作のみです。

何も信用しないでください。すべてのリクエストは攻撃です。すべてのユーザーはハッカーです。この考え方で開発すれば、アプリケーションははるかに安全で安定し、悪意のあるユーザーに乗っ取られる可能性が低くなります。あなたのデータ（あなたの最も貴重なリソースの 1つ）に深刻な問題を抱えているために、あなたのセキュリティを回避する方法を見つけるのに1人の賢い人しかいません。

アプリケーションにセキュリティホールが見つかった場合は、ギャップを埋めるために必要と思われるすべてのことを実行してください。特に、APIは、存在する中で最も信頼性の低いソフトウェアである必要があります。資格情報を要求し、Postリクエストに進みます。

コードが確立され維持されている場合、エッジケースを調べて、ケースバイケースで対処する必要があります。

私の部分のいくつかのエラーによる修正：

GETは、適切なRESTfulサービスの一部として引き続き使用する必要があります。いずれにしても、認証が存在する必要があります。私が推測しようとしていたことは、セキュリティ上の目的でGETはPOSTとほとんど同じですが、ポストは情報をアドレスバーに入れずに動作するため、セキュリティ上の大きな違いになる傾向があります（そしてGETが嫌いな理由） @Leeによる投稿、

GET requests are used to retrieve resources, and PUT/POST are used to add/update 
resources so it would be completely against expectations for a RESTful API to use
PUT/POST to get data. 

これはサードパーティのアプリケーションで使用されるため、RESTfulサービスの適切なプラクティスに従って、この部分でエンド実装者が混乱しないようにする必要があります。

ユーザーが積極的に悪意のあることを含め、すべてのもっともらしい不測の事態を考慮し、「巧妙なセキュリティ」バリアを（成功して）リバースエンジニアリングする必要があります。

しかし、同時に、成功ハックの影響と、試行が行われる可能性を評価する必要があります。例えば：

• 強固なファイアウォールで保護された内部サービスは、パブリックインターネット上のサービスよりも攻撃を受けにくい。

• 誰かが顧客のディスカッションフォーラムを倒すことの影響は、顧客がクレジットカードを盗むことの影響よりも小さくなります。

私のポイントは、「完全なセキュリティ」は「無限に高価」であり、実際には達成できないということです。理想的には、徹底した費用便益分析に基づいて、どこに線を引くかを決定する必要があります。