前言三年前的時候寫了一篇文章：輕鬆理解 AJAX 與跨來源請求，提到了串接 API、AJAX、same-origin policy、JSONP 以及 CORS，當時把自己想講的都放進去了，但現在回頭看，好像有很多滿重要的部分沒有提到。 三年後，再次挑戰這個主題，並且試著表達地更完整。 會想寫這個系列是因為在程式相關的討論區上，CORS 是發問頻率很高的主題，無論是前端或是後端都有可能來問相關的問題。 所以我就想說：「好，那我來寫一個系列好了，我要試著把這個主題寫到每個碰到 CORS 問題的人都會來看這個系列，而且看完以後就知道該怎麼解決問題」，這算是我對這篇文章的目標，如果文章的品質沒辦法達成這個目標，我會持續改進。 這系列一共有六篇文章，分別是： CORS 完全手冊（一）：為什麼會發生 CORS 錯誤？ CORS 完全手冊（二）：如何解決 CORS 問題？ CORS 完全手冊（三）：CO
クロスオリジンのリクエストを安全にするための同一生成元ポリシーとオリジン間のリソース共有（CORS）の仕組みをGIFアニメで解説した記事を紹介します。 ✋🏼🔥 CS Visualized: CORS by Lydia Hallie 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに ✋🏼同一生成元ポリシー（Same-Origin Policy）とは 🔥クライアントサイドのCORS 💻サーバーサイドのCORS 🚀プリフライト リクエスト（Preflighted Requests） 🍪認証 はじめに 「Access to fetched to fetched has been blocked by CORS policy error」と赤い文字がコンソールに表示されると、デベロッパーなら誰でもフラストレーションが
概要 Github https://github.com/kaishuu0123/cors-reverse-proxy Docker Hub (コンテナイメージもあります) https://hub.docker.com/r/kaishuu0123/cors-reverse-proxy ユースケース ローカルの開発環境などに アプリケーションの連携をする際に、特定のアプリは信用して、リソース(画像や JS など)の読み込みを行いたいときに 具体例がちょっと微妙かもしれませんが、「GROWI と draw.io を連携する際に、draw.io からの読み込みは信用したい」というケースがありました。 (PR はこちら) 作ったモチベーション とにかくシンプルに「Access-Control-Allow-Origin: * ヘッダを付けるだけ」のコンテナがあってもいいんじゃないかな、と思ったからで
はじめに モバイルアプリや、マイロサービスが進んできている昨今において、リクエスト元とリクエスト先のドメインが必ず同じとは限らない状況が多々あると思います。 そこで、Javascriptだと回避策としてJSONP使うかCORS設定するか？がメジャーどころですが、今回は後者のCORS設定についてです。 HTTPサーバーはNginxを利用しています。 直面した事 NginxでCORS設定していて、何らかの原因、例えばサーバーサイドのプログラムにエラーがあって500番のHTTPレスポンスが返されるとします。その場合に、なぜかCORSのエラーが出るといった現象に遭遇しました。 localhost:5555→localhost:1000 にリクエストした時に502 BadGatewayをわざと発生させて、そうするとアクセス元のブラウザではCORSのエラーが出ます。 Javascriptで開発している
✎ 基礎知識編 CSRF とは何か？ CSRF (Cross-Site Request Forgeries) を意訳すると 「サイトを跨ぐ偽造リクエスト送信」 です。 簡単に言うと，罠サイトを踏んだ結果，自分が無関係な別のサイト上で勝手にアクションをさせられる攻撃です。具体的には，ネットサーフィンをしているうちに知らない間に自分のIPアドレスから掲示板に犯罪予告が書かれていた，といった被害を受けます。 この攻撃を防ぐ責任は「無関係な別のサイト（具体例では掲示板）」側にあります。Web サイト作成者には，利用者が意図しない操作を勝手に実行されないように，利用者を守る責任があります。 また上図からも分かる通り，この攻撃の最大の特徴はアカウントがハッキングされたというわけではないということです。ログイン状態の利用者のWebブラウザを利用して攻撃が行われている，というのが重要です。 オリジンとは何
“OK, but no”If you ever worked with an AJAX call, you are probably familiar with the following error displayed in browser console: Failed to load https://example.com/: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘https://anfo.pl' is therefore not allowed access. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resour
Webアプリを開発時に、クロスドメイン制約でAPIと通信が出来なかったので、開発環境側で対応する方法を考えて見ました。 外部公開用のAPIであれば、サーバー側でCORS仕様に対応する必要があるのでさっさと対応してもらいましょう。 →外部公開のAPIサービス見た所 Originを超えたアクセスを許可するヘッダーを返しているサービスが見当たらずJSONP等の対応が多いように感じました。 今回の場合では、運用環境ではAPIとWebアプリは同じドメイン上に存在し、開発時にlocalhostとAPIでクロスドメインになってしまうというパターンです。 どうやって対応するの？ Web Debugging Proxy を使うか SPA開発時に利用するビルドツールの proxy 機能を利用します。 Fiddler (Windowsのみ, 無料) Charles (Windows/Mac/Linux, 有料
25 May 2011 2011-10-5 仕様の変更に伴い、大部分を書きなおす。 経緯 僕は今まで、ブラウザのクロスドメイン通信の制約とは、ホスト等が異なるサーバへのアクセスをブラウザが禁止する事だと思っていました。しかし、Chrome Extensionを開発中にどうもそれでは説明が付かない事があり、クロスドメイン通信に関して基本から学び直す機会があったので、せっかくなのでまとめました。この記事の結論を先に言うと、CORSという標準化されたクロスドメイン通信制約のもとでは、ブラウザは主にレスポンスを検閲する、という事です。 ただし、以下の文章は私が個人的に調べた事をまとめたものであり、正しさの保障はありません。むしろ間違いを見つけたら、指摘して頂けるとありがたいです。 なぜクロスドメイン通信が制約されるのか まずは基本から。 ブラウザ上のスクリプトが行うクロスドメイン通信には、ご存知の
クロスオリジンの通信を成立させるためには、サーバ側が返すレスポンスに以下のHTTPヘッダを付与する必要があります。 Access-Control-Allow-Origin: <FQDN> | * を追加する 特定のドメイン(https://example.com)か、全てのドメイン(*)を許可するようにヘッダを設定できます FQDN か "*" のみ許可されます。カンマで復数のドメインやサブドメインを列挙することはできません(エラーになります) "https://*.example.com" はエラーになります "example.com" はFQDNではないためエラーになります。"https://example.com" とします "https://example.com" と設定した場合は、サブドメインの "https://www.example.com" からのアクセスは許可されません
タイトルは釣り、かつ、自分のための備忘録です。 マイクロサービスアーキテクチャでサービスを構築すると、APIサーバをサービスごとに立てるわけですが、 ブラウザ上のJSエンジンからAPIサーバを叩く時に避けて通れないのが、Same-Origin Policy（同一生成元ポリシー）によるCORS (Cross-Origin Resource Sharing)制限です。 これを回避するには、APIサーバ側でAccess-Control-*ヘッダを適切に返す必要がありますが、どう設定するべきかの情報が意外と少ないので（自分的）これが決定版！ という設定を考えてみました。 結論 nginxの場合の設定例です。 server { listen 80; server_name site.localhost; charset utf-8; root /var/www/app/public; locatio
一度きちんと整理しておきたし。 オリジンとは URLのscheme, host, portによって定義される。以下、いずれも違うオリジンになる。 http://example.com https://example.com http://sub.example.com http://example.com:8080 同一生成元ポリシー 英語で言うと、Same Origin Policy。 http://www.w3.org/Security/wiki/Same_Origin_Policy を読むと、いきなり"There is no single same-origin policy." と書かれている。。。が、一般原則はある。 https://developer.mozilla.org/ja/docs/Web/JavaScript/Same_origin_policy_for_JavaSc
今更ですが、**CORS (Cross-Origin Resource Sharing)**を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。 そもそも 現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日本語では同一生成元ポリシー)が適用されます。 例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。 しかし、アクセス元が悪意あるWebサイトならともかく
こちらは ピクシブ株式会社 Advent Calendar 2014 の12/16の記事です。 こんにちは、エンジニアの@dnskimoです。 先日、はじめてCORSを実装する機会があったので、覚書がてらまとめておきたいと思います。 CORSとは Cross-origin resource sharingの略です。 読み方は「コルス」でいいんでしょうか？ Same-Origin Policyに弾かれずに、異なるドメイン間でリソースを共有する仕組みです。 2014年1月にW3C勧告になり、JSONPに替わる方法として徐々に普及してきているようです（要出典）。 アクセスコントロールの仕様も定義されているので、特定のサイトからのみ利用可能なAPIを作る際などに便利です。 JSONPのような「裏ワザ」的な方法ではないところも個人的に好みです。 詳しいことはネット上に素晴らしい記事がたくさんあるので
![CORSでハマったことまとめ - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/70054759c3787b5c8b89449617d22d699ef3b8f9/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F4393f2761db895fd0a5106a3761d1fe12d734abe%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttp%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fd%252Fdevpixiv%252F20141216%252F20141216151227.jpg)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
