RestfulAPIに「x-frame-options」を追加することは意味がありますか
いくつかのさまざまなイベントを実行するRESTfulAPIを開発しています。 Nessusの脆弱性スキャンを実行して、セキュリティリークを確認しました。クリックジャッキングにつながるリークがいくつかあることが判明し、解決策を見つけました。私が追加しました x-frame-options as SAMEORIGIN問題を処理するため。
ここでの私の質問は、私はAPIなので、クリックジャッキングを処理する必要があるということです。サードパーティのユーザーはiframeを介して私のAPIにアクセスできるはずであり、これを処理する必要はないと思います。
私は何かが恋しいですか？あなたのアイデアを共有していただけませんか？
2019-10-07を編集：@ Taytayの [〜＃〜] pr [〜＃〜] がマージされたので、 OWASPの推奨事項では、サーバーはX-Frame-Optionsヘッダーを送信する必要があると記載されています。
元の回答：
OWASP推奨clientsはX-Frame-Optionsヘッダーを送信しますが、API自体については言及していません。
APIがクリックジャッキングセキュリティヘッダーを返すことが意味をなさないシナリオは見当たりません-iframeでクリックするものは何もありません！
OWASP推奨 X-Frame-Optionsヘッダーを送信するだけでなく、DENYに設定されていること。
これらは、Webサイトではなく、RESTサービスに対する推奨事項です。
これを行うことが理にかなっているシナリオは、まさにOPが言及したシナリオであり、脆弱性スキャンを実行します。
正しいX-Frame-Optionsヘッダーを返さないと、スキャンは失敗します。これは、エンドポイントが安全であることを顧客に証明するときに重要です。
ヘッダーの欠落が問題にならない理由を議論するよりも、合格レポートを顧客に提供する方がはるかに簡単です。
X-Frame-Optionsヘッダーを追加しても、iframeを備えたブラウザーではないため、エンドポイントコンシューマーに影響を与えることはありません。