今さら聞けないSPAのCORS対策の話東京Node学園2017にて発表しました。
SRI をビルドプロセスへ組みこもう
この記事は “How to implement SRI in your build process” の抄訳です。 顧客から「おたくのサイトがマルウェアを配布している」との連絡があった場合を想像してみてください。心臓は止まり、冷汗をかき、Tweet が溢れ始めるでしょう。 「あれ？おかしいぞ」 システムは汚染されていませんでした。 実際にハッキングされたのはWeb サイトで利用しているスクリプトを配布している CDN のプロバイダで、そのスクリプトがマルウェア化していたのでした。そこで顧客に事実を報告しましたが、彼らは気にしません。製品の安全性と、顧客からの信頼は失われてしまいました。これが 2 年前に起きたとしたら、 「気の毒なことだったね」 と言ったでしょう。しかし今ならこう言うでしょう： 「SRI を使うべきだ」 Subresource Integrity (SRI) は比較的新しい
同一オリジンに境界を設ける Suborigins とは - ASnoKaze blog
Webセキュリティを考える上で大事な仕組みの一つに、Same-Origin Policyという仕組みがあります。 Originは「スキーム・ホスト・ポート」の組み合わせです。これらが一緒であれば、同一Originでありリソースへアクセスすることができます。 歴史的経緯や様々な理由により複数のアプリケーションが同一Originで提供されている場合があります。 たとえば、"チャット"や"ショッピング"の機能が以下の様なURLで提供されているような場合です。 https://example.com/chat/ https://example.com/shopping/ 実際、Googleの検索サービスと地図サービスは同一Originで提供されています。昔からあるリンクや、パフォーマンス、ブランディングのためのようです。 https://www.google.com https://www.goo
Subresource Integrityについて調べた
Subresource Integrity という記事をみて、 ちょっと興味深かったのでSubresource Integrityについて、軽く見てみた。 Subresource Integrityはどういうものかおそらく、以下のようなもの。 ウェブアプリケーションでCDNをつかって、サブリソースを参照することは当たり前になっている。 しかし参照先のサブリソースが安全であるという保証はない。 もし、CDN経由で参照しているサブリソースが攻撃者により改変された場合、XSSの危険性が生じる。 これは、サブリソースの整合性をチェックする仕組みを導入することで、危険を回避できる。 Subresource Integrityとは、サブリースをSHA256, SHA512などでハッシュ化して、linkタグやscriptタグにintegrity属性として付与することで、整合性を確認できるようにしたもの。
CORSでハマったことまとめ - pixiv inside [archive]
こちらは ピクシブ株式会社 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/5f6a93da881857fccf6161c1a2f6935458bfbb97/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fd%2Fdevpixiv%2F20141216%2F20141216151227.jpg)
Fetch Standard （日本語訳）
Fetch Standard （日本語訳） Fetch Standard 日本語訳 このページ は、 WHATWG による， 2013 年 8 月 30 日時点の Fetch Standard を日本語に翻訳したものです。 この翻訳の正確性は保証されません。 この仕様の公式な文書は英語版であり、この日本語訳は公式のものではありません。 【 と 】で囲まれた部分は【訳者による注釈】です。 （他のウェブ関連仕様の一覧と共通機能の詳細） 更新： 2013-08-30 （公開： 2013-04-27） このページの大部分はスクリプトにより生成されています（ 古いブラウザなど，一部のブラウザには対応していません： 生成中…この表示が消えない場合はどこかでエラーが生じています）。 本文ダブルクリックで当該箇所の原文が表示されます（左下隅に各種 表示切替ボタン — CSS や DOM の対応が古いブラウ
[新機能] Amazon CloudFrontがCORSに対応しました | DevelopersIO
特に問題となるのがS3の場合でした。EC2インスタンス上のWebアプリケーションであればOriginヘッダの有無に関係なくAccess-Control-Allow-Originヘッダを返すこともできますが、S3のCORS機能は仕様通りの実装であるためOriginヘッダが存在しない場合はAccess-Control-Allow-Originヘッダを返しません。具体的には、以下の様な挙動になります。まずはOriginヘッダをつけない（同一ドメイン）の場合です。curlコマンドでStatic Website Hostingを有効にしたS3バケットhoge.example.com.s3-website-ap-1.amazonaws.comに対してアクセスします。 $ curl -I hoge.example.com.s3-website-ap-1.amazonaws.com/hoge HTTP/1
![[新機能] Amazon CloudFrontがCORSに対応しました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/05bf92c3dad6e282bf2cded7bb4b61f42547e50e/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FAmazon_CloudFront.png)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RFC7231のリファラに関するメモ