Webサーバーは同一生成元ポリシーをどのように実施しますか？

私はRESTful APIの開発により深く取り組み、これまでにいくつかの異なるフレームワークと連携してこれを実現してきました。もちろん、私は同じ起源のポリシーに遭遇しましたが、今では（Webブラウザーではなく）Webサーバーがどのようにそれを実施するのかと思っています。私が理解していることから、ブラウザの最後にいくつかの強制が行われているようです（たとえば、サーバーから受信したAccess-Control-Allow-Originヘッダーを尊重します）。しかし、サーバーはどうですか？

たとえば、WebサーバーがAPIにアクセスするJavascript Webアプリをホストしており、そのサーバーでもホストされているとします。私は、サーバーが同一生成元ポリシーを適用すると想定しているため、そのサーバーでホストされているJavaScriptのみがAPIにアクセスできるようになります。これにより、他の誰かがそのAPIのjavascriptクライアントを記述して別のサイトでホストすることを防ぐことができますか？それでは、Webサーバーは、同じWebサーバーから発信されたjavascriptを実行していると主張しながら、APIエンドポイントにAJAXリクエストを行おうとする悪意のあるクライアントをどのように停止できますか？最も一般的なサーバー（Apache、nginx）は、この種の攻撃からどのように保護しますか？または、これについての私の理解は何とか外れていますか？

または、クロスオリジンポリシーはクライアントエンドでのみ実施されますか？

同じ発信元ポリシーは完全にクライアントベースの制限であり、主にサービスではなくユーザーを保護するように設計されています。すべてまたはほとんどのブラウザには、コマンドラインスイッチまたはそれをオフにする構成オプションが含まれています。SOPは車のシートベルトのようなものです。車のライダーを保護しますが、誰でも自由に使用できます。確かに、人のシートベルトが車から出てあなたを攻撃する（またはWebサービスにアクセスする）のを防ぐとは思わないでください。

Webサービスにアクセスするプログラムを作成するとします。これは、HTTP要求を含むTCPメッセージを送信するプログラムです。私のプログラム（何でも送信できる）によって行われた要求と、許可されたオリジンからロードされたページを持つブラウザーによって行われた要求を区別するサーバー側のメカニズムを求めています。それは単純にできません。私のプログラムは、Webページによって形成されたリクエストと常に同じリクエストを送信できます。

同じ起源のポリシーは、あるWebサイトのコードが別のサイトの資格情報に制限されたコンテンツにアクセスできないようにするために考案されました。Ajaxリクエストは、デフォルトで、ターゲットサイトによって許可された認証Cookieとともに送信されます。たとえばhttp://evil.com/、にリクエストを送信するを誤ってロードしたとしますhttp://mail.google.com/。SOPが設定されておらず、Gmailにサインインしている場合、スクリプトevil.comは私の受信トレイを見ることができました。サイトが私のCookieなしでevil.comロードしたい場合、mail.google.comプロキシサーバーを使用できます。の公開コンテンツはmail.google.com秘密ではありません（ただしmail.google.com、Cookie を使用してアクセスしたときのコンテンツは秘密です）。

同一生成元ポリシーは、クライアント側で実施されます。ブラウザがCORSをサポートしている場合、サーバーは、同一生成元ポリシーの例外を作成するようブラウザに指示するヘッダーを送り返すことができます。たとえば、ヘッダーを送信する

 Access-Control-Allow-Origin: www.example.com

ブラウザにwww.example.comからのクロスオリジンリクエストを許可するように指示します。

 Access-Control-Allow-Origin: *

そのリソースに対するすべてのクロスオリジンリクエストを許可するようブラウザに指示します。

Webサーバーは通常Referer、HTTPヘッダー内の（誤ってつづりが間違っている）行をチェックし、要求が自分のサイトのページから送信されていることを確認することで、この種の攻撃を防ぎます。悪意のあるクライアントから保護する良い方法はありませんが、それはXSRF攻撃の仕組みではありません。

クライアントは悪意のあるものではありません。通常、悪意のある第三者によってだまされて、クライアントの保存されたCookieを使用してHTTPリクエストをサイレントに行うドキュメントを開くように仕向けられた普通のユーザーです。そのため、サーバーがRefererHTTPリクエストがMyAwesomeWebsite.comではなくgmail.comからのものであることを確認できれば、攻撃をシャットダウンできます。

Webサーバーは同一生成元ポリシーをどのように実施しますか？

要するに、アサイラーとダークが指摘したように、彼らはそうしません。
重要な理由の1つは、ACAOヘッダーが、サーバー自体をD延するDDOS、つまり分散型サービス拒否攻撃から保護することです。

誰：

HTTP応答ヘッダーとしてのACAOは、Webクライアントが解釈されることを意図しており、人間のインターネットユーザーの大多数がW3C推奨ドラフトを遵守および実装する主要なブラウザーベンダーを通じてWebを閲覧しているという前提の下で動作します。ほとんどすべての人は、高速でアクセス可能なインターネットの恩恵を受けるはずです。

どうやって：

それ以外の場合は、単純なループを実行する悪意のあるWebサイトにJavaScriptコードの数行をコピーして貼り付けるだけで、Ajax GETまたはPOSTの外部ドメインへの要求が行われます。ユーザーとの対話、およびマルチスレッド機能なし。

そのため、ACAO HTTPヘッダーを使用して、クロスオリジンサイトにアクセスするにはオプトインする必要があります。あなたは、ユーザーは、ユーザーが認識する対話、つまりインターネットリンクを介していつでもサイトにアクセスできます。クリップボードとの間でユーザーがコンテンツをコピーまたは貼り付けできるように、プラグインは別として、他の方法ではできません。

未来：

その時点で、Webブラウザメーカーの次の方向に注意してください。

• 完全なサンドボックス環境へのステップとしてのデフォルトのプラグイン削除
• JavaScriptをオフにするユーザーオプションを削除する

TSL 2/3、強力なセッションID、TAN、2要素認証などの組み合わせを使用して、セキュリティ制限を適切に確立できます。

「Google」にはDDOSを表示して発言する機能があります

最後に、誰でもWebコンテンツをプロキシし、目的のACAOヘッダーを追加して、プロキシされたクロスサイトコンテンツにアクセスできます。同様に、このプロキシは、ACAO設定で許可されているように、DDOS攻撃に対して開かれています。私は実際に、単一の無料の公共サービスの提供を知りません。私が間違っている場合は修正してください。

他の人が言ったように、それはクライアント次第です。ただし、サーバーはSOPをバイパスするXSSを処理する必要がある場合があります。

サーバーをサポートすることで、ユーザーはコンテンツをアップロードできます。これは、他のユーザーがサイトを閲覧するときに表示されます。このページは良い例です-コンテンツをアップロードしたばかりで、あなたに表示されます。
コンテンツに<script>タグが含まれており、サーバーが生成したHTMLにコピーするだけの場合、アップロードしたスクリプトが実行されます。
スクリプトはファイルのHTMLで見つかったため、サイトのスクリプトのすべての権限を持っています。たとえば、この答えに賛成票を投じることができます。そして、これがこの答えが非常に多くの賛成票を持っている理由です。

優れたWebサーバー（悲しいかな、StackExchangeが使用するサーバーなど）は、これを実現させません。<script>タグを削除するかエスケープすることができるため、表示されますが実行されません（警告-この答えは、XSSを防ぐための信頼できるレシピとはほど遠いです）。

したがって、SOPを強制するのはクライアント側ですが、場合によっては、サーバーはそれをバイパスしないように動作するはずです。