Webサーバーはどのようにして同一オリジンポリシーを適用しますか？
私はRESTful APIの開発に深く取り組んでおり、これまでにいくつかの異なるフレームワークを使用してこれを実現しています。もちろん、同じオリジンのポリシーに出くわしましたが、今は（Webブラウザーではなく）Webサーバーがそれをどのように実行するのか疑問に思っています。私が理解していることから、ブラウザの最後でいくつかの強制が発生しているようです（たとえば、サーバーから受信したAccess-Control-Allow-Originヘッダーを尊重するなど）。しかし、サーバーはどうですか？
たとえば、Webサーバーが、そのサーバーでホストされているAPIにアクセスするJavaScript Webアプリをホストしているとします。私はサーバーが同じオリジンポリシーを適用すると想定しています---そのサーバーでホストされているJavaScriptのみがAPIへのアクセスを許可されます。これにより、他の誰かがそのAPIのJavaScriptクライアントを作成して別のサイトでホストするのを防ぐことができます。では、同じWebサーバーから発信されたJavaScriptを実行していると主張しながら、そのAPIエンドポイントにAJAXリクエストを送信しようとする悪意のあるクライアントをWebサーバーが停止できるようにするにはどうすればよいですか？最も人気のあるサーバー（Apache、nginx）はこの種の攻撃から保護しますか？または、これに対する私の理解が何らかの形で適切ではありませんか？
または、クロスオリジンポリシーはクライアントエンドでのみ適用されますか？
同じOriginポリシーは完全にクライアントベースの制限であり、主にsersではなくservicesを保護するように設計されています。すべてまたはほとんどのブラウザには、コマンドラインスイッチまたはそれをオフにするための設定オプションがあります。 SOPは車のシートベルトのようなものです：それらは車のライダーを保護しますが、誰もが自由にそれらを使用しないことを選択できます。確かに期待しないでください車から降りてあなたを攻撃する（またはWebサービスにアクセスする）のを防ぐための人のシートベルト。
Webサービスにアクセスするプログラムを書いてみます。 HTTPリクエストを含むTCPメッセージを送信するのは単なるプログラムです。サーバー側のメカニズムで、私のプログラムによるリクエスト（何でも送信できます）と許可されたOriginから読み込まれたページを持つブラウザです。これは単に実行することはできません。私のプログラムは、常にWebページによって形成されるものと同じ要求を送信できます。
同じオリジンポリシーは、あるWebサイトのコードが別のサイトのcredential-restricted contentにアクセスできないようにするために考案されました。 Ajaxリクエストはデフォルトで、ターゲットサイトによって許可された認証Cookieとともに送信されます。たとえば、http://evil.com/へのリクエストを送信するhttp://mail.google.com/を誤ってロードしたとします。 SOPが設定されておらず、Gmailにサインインしている場合、evil.comのスクリプトが私の受信トレイを表示する可能性があります。evil.comのサイトがmail.google.com私のCookieがなくても、プロキシサーバーを使用できます。mail.google.comの公開コンテンツは秘密ではありません（ただし、私のCookieでアクセスした場合のmail.google.comのコンテンツareシークレット）。
同じオリジンポリシーがクライアント側で適用されます。ブラウザーが [〜＃〜] cors [〜＃〜] をサポートしている場合、サーバーはブラウザーに同じオリジンポリシーに例外を作るように指示するヘッダーを送り返すことができます。たとえば、ヘッダーを送信する
Access-Control-Allow-Origin: www.example.com
ブラウザにwww.example.comからのクロスオリジンリクエストを許可するように指示します。
Access-Control-Allow-Origin: *
そのリソースへのクロスオリジンリクエストをすべて許可するようブラウザに指示します。
Webサーバーは通常、HTTPヘッダーの（悪意のあるスペルが間違っている）Referer行をチェックして、要求が自分のサイトのページから送信されていることを確認することにより、この種の攻撃を防ぎます。悪意のあるクライアントを防御する良い方法はありませんが、XSRF攻撃が機能する方法はこれではありません。
クライアントは悪意のあるものではありません。通常、悪意のあるサードパーティにだまされて、クライアントの保存されたCookieを使用してHTTPリクエストを静かに作成するドキュメントを開くようにだまされた通常のユーザーです。そのため、サーバーがRefererを介して、HTTPリクエストがMyAwesomeWebsite.comではなくgmail.comからのものであることを確認できる場合、攻撃をシャットダウンできます。
Webサーバーはどのようにして同じオリジンポリシーを適用しますか？
要するに、apsillersとDirkが指摘したように、それらはそうではありません。
1つの重要な理由は、ACAOヘッダーが蔓延するDDOSからサーバー自体を保護することです-分散型サービス拒否攻撃。
Who：
HTTP応答ヘッダーとしてのACAOは、Webクライアントが解釈され、人間のインターネットユーザーの大多数が準拠および実装している主要なブラウザーベンダーを通じてWebを閲覧しているという前提の下で動作することを意味します W3C推奨草案 。彼らは、結局のところ、ほとんどが高速でアクセス可能なインターネットの恩恵を受けるはずです。
方法：
それ以外の場合は、単純なループを実行する悪意のあるWebサイトに数行のJavaScriptコードをコピーして貼り付けるだけで、外部ドメインへのAjax GETまたはPOST要求を実行できます。ユーザーとのやり取りがなく、マルチスレッド機能。
そのため、あなたは、ACAO HTTPヘッダーを介してクロスオリジンサイトにアクセスするためにオプトインする必要があります。ユーザーは、ユーザー認識の相互作用、つまりインターネットリンクを介して、いつでもこのサイトにアクセスできます。クリップボードとの間でユーザー対応のコンテンツをコピーまたはペーストできるのと同じように、プラグインは別として、他の方法ではできません。
将来：
その時点で、ウェブブラウザメーカーの次の指示に注意してください。
- デフォルト プラグインの削除 、完全にサンドボックス化された環境へのステップとして
- JavaScriptをオフにするユーザーオプションを削除
TSL 2/3、強力なセッションID、TAN、2要素認証などの組み合わせを使用して、セキュリティ制限を適切に確立できます。
「グーグル」はこれを表示し、言うためにこれを持っています [〜＃〜] ddos [〜＃〜]
最後に、誰でも任意のWebコンテンツを自由にプロキシし、プロキシされたクロスサイトコンテンツにアクセスするために必要なACAOヘッダーを追加できます。同様に、このプロキシは、ACAO設定で許可されているのと同じように、DDOS攻撃に対してオープンです。私は実際には、単一の無料の公共サービスの提供を知りません。私が間違っていたら訂正してください。
他の人が言ったように、それはクライアント次第です。ただし、サーバーはSOPをバイパスするXSSを処理する必要がある場合があります。
サーバーをサポートすると、ユーザーはコンテンツをアップロードできます。コンテンツは、他のユーザーがサイトを閲覧したときに表示されます。このページは良い例です-私はコンテンツをアップロードしただけで、あなたに表示されます。
コンテンツに<script>タグが含まれていて、サーバーがそれを生成するHTMLにコピーするだけの場合、アップロードしたスクリプトが実行されます。
スクリプトはファイルのHTMLで見つかったため、サイトのスクリプトのすべての権限を持っています。たとえば、この回答に賛成票を投じることができます。そして、これがこの回答に非常に多くの賛成票がある理由です。
（残念ながら、StackExchangeが使用しているような）優れたWebサーバーでは、これは起こりません。 <script>タグを削除したり、エスケープしたりして、表示されても実行されないようにすることができます（警告-この回答は、XSSを防ぐための信頼できるレシピとはほど遠いものです）。
したがって、SOPを実施するのはクライアント側ですが、場合によっては、サーバーがバイパスしてSOPを回避する必要があります。