Chrome113でHTTPヘッダを上書きしていろんな状態をお試しできる - hogashi.*
Chrome 113 で、 DevTools の Network ペインで HTTP ヘッダを好きなように編集して、いろんな状態をお試しできるようになっている。 What's New in DevTools (Chrome 113) - Chrome Developers で紹介されている。 GitHub から example.com を fetch してみる GitHub の CSP ヘッダを上書き example.com の CORS のヘッダを上書き 途中で指定したフォルダの中身は何？ 上書きをやめるには？ 感想 GitHub から example.com を fetch してみる 試しに、 CSP で外部への通信がそれなりに制限されている GitHub から、 example.com への fetch を成功させてみる (外部サイトへの通信は、認証情報や秘密の情報の漏洩などに気をつ
CORSの仕様はなぜ複雑なのか
Webアプリケーションを実装していると高確率で CORS の問題にぶつかります。CORSがどのようなものかはリンクしたMDNなど既存の解説を読むのが手っ取り早いと思いますが、「なぜそのように設計されたのか」という観点での説明はあまり見ないため、昔の資料の記述や現在の仕様からの推測をもとに整理してみました。 CORSとは 現代のWebはドメイン名をもとにした オリジン (Origin) という概念 (RFC 6454) をもとに権限管理とアクセス制御を行っています。その基本となるのが以下のルールです。 Same-origin policy (同一生成元ポリシー): 同じオリジンに由来するリソースだけを制御できる。 上記Wikipedia記事によるとSOPの概念は1995年のNetscape 2.02に導入されたのが最初のようです。当時のドキュメンテーションを読む限り、これはウインドウ越しに別
Site Isolation 及び Web のセキュリティモデルの更新 | blog.jxck.io
Intro Origin は Web におけるセキュリティモデルの一つとして、コンテンツ間の Communication に関する境界を定義し、リソースを保護してきた。 しかし、 Spectre の発覚以降、 Communication に関する制限だけではなく Isolation によるメモリレベルでのアクセス制御が必要となった。 そこで現在作業されているのが、 CORB, CORP, COEP, COOP といった仕様群であり、これは Web におけるセキュリティモデルの更新作業と見ることができる。 概要と現状について解説する。 DEMO & Resources 量が多いため、動作する DEMO と関連リソースは、ページ下部にまとめてある。 CORS による Cross Origin Communication の制限 CORS は、平たく言えば、リソース提供元(サーバ)が、クライアン
Making your website "cross-origin isolated" using COOP and COEP | Articles | web.dev
Making your website "cross-origin isolated" using COOP and COEP Stay organized with collections Save and categorize content based on your preferences. Use COOP and COEP to set up a cross-origin isolated environment and enable powerful features like SharedArrayBuffer, performance.measureUserAgentSpecificMemory() and high resolution timer with better precision. Updates June 21, 2022: Worker scripts
異なるドメイン間でlocalstorageを共有する方法 - Qiita
はじめに localStorageは基本的に同じドメイン内（厳密にはポート番号なども一致している必要がある）でしか有効ではありませんが、postMessage API（Web Messaging API）を使用することでクロスドメインでも共有することができます。 調べてみても古い記事が多かったり、サンプルのコードが無かったりだったので自分用の備忘録も兼ねてやり方をご紹介します。 構成 【ドメインA】 ・localstorageのデータを持つ側。 ・ドメインBからの要求に応じてlocalstorageの操作を行う。 【ドメインB】 ・ドメインAに保存されているlocalstorageの値の参照や更新を要求する側。 （実際の動作確認はA側をGithub Pages、B側をローカルサーバーに置いた状態で行いました。） ドメインA側 ドメインB側からのメッセージをトリガーにlocalstorage
ServiceWorkerはSameOriginを超えられるのか
ServiceWorkerはSameOriginを超えられるのか 結論 キャッシュには入れられる キャッシュの内容には触れられない ServiceWorkerではなくFetch APIの領域 Fetch API ServiceWorker内ではfetchやnew Requestを使用 modeを指定する事で"same-origin", "no-cors" , "cors" を選べる "no-cors"を指定するとsame-originを無視してデータを取れる fetch("http://example.com/", { mode: 'no-cors' }); // サーバ側でCORS未対応でもデータを取得出来る // 返されるデータはopaque filtered responseとなる 'opaque' filtered response? same-originを無視して取得したデータ
AWSサーバーレスを活用したAngularのWebアプリを作ってみた - Taste of Tech Topics
こんにちは！エンジニア2年目、フロントエンドを勉強中のmiuraです。 この記事はAmazon Web Services Advent Calendar 2017の13日目の記事となります。 qiita.com 私は最近、Angularを使ったフロントエンド開発やAWSでのサーバーレス開発をしているのですが、 サーバーレスのWebアプリを構築するとなった際につまった部分がありました。 それは、 WebアプリをS3に、サーバーレスをAPI GatewayとAWS Lambdaで構成すると双方のURLが違うため、 ブラウザではSame-Origin Policy (SOP)が適用されてエラーになってしまうことです。 これを回避するためにはCross-Origin Resource Sharing (CORS)の設定を行う必要があります。 今回は、そのCORSの設定を含めてAWS上で一通りの動き
APIサーバを立てるためのCORS設定決定版 - Qiita
タイトルは釣り、かつ、自分のための備忘録です。 マイクロサービスアーキテクチャでサービスを構築すると、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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
same-site/cross-site, same-origin/cross-originをちゃんと理解する