はじめに こんにちは。クロスイノベーション本部サイバーセキュリティテクノロジーセンターの小笠原です。 昨今の脆弱性検査において、以下のHTTPレスポンスヘッダの未設定が検出されるケースが増えています。 COEP（Cross-Origin-Embedder-Policy） CORP（Cross-Origin-Resource-Policy） COOP（Cross-Origin-Opener-Policy） これらはブラウザが提供する「クロスオリジン分離（Cross-Origin Isolation）」を実現するためのセキュリティ機能です。 「設定すると何が変わるのか」「対応は必須なのか」と疑問に思った方もいるのではないでしょうか。 本記事では脆弱性検査の観点からCOEP、CORP、COOPヘッダの役割や検出される理由について紹介します。 なぜ脆弱性検査で指摘されるのか これらのヘッダは以下の観点からセキュリティ強化項目として扱われています。 Spectreのようなサイドチャネル攻撃への対策 一部の高度なブラウザ機能を安全に利用するための要件への対応 昨今のブラウザでは安全な実行環境を確保するため、一部の高度なブラウザ機能を利用する際に「クロスオリジン分離」と呼ばれる状態が求められています。 そのため、脆弱性検査では以下のような観点が確認項目として指摘されるケースが増えています。 ブラウザセキュリティ強化への対応状況 クロスオリジン分離への対応状況 Spectreなどの新しい脅威への備え とはいえ「クロスオリジン分離」や「Spectre」といった言葉に馴染みがない方もいるかと思います。 次章ではまず、本記事を読むにあたって前提となる知識を整理します。 前提知識 本記事を読むにあたり、前提となる用語を先に整理します。 オリジンとは オリジンとはWebサイトを識別する単位であり、スキーム・ホスト名・ポート番号の3つの組み合わせで構成されます。 この3つがすべて一致する場合のみ「同一オリジン」、1つでも異なる場合は「別オリジン（クロスオリジン）」として扱われます。 比較対象 判定 理由 https://example.com と https://example.com/page 同一オリジン スキーム・ホスト・ポートが一致（パスは無関係） https://example.com と https://sub.example.com 別オリジン ホスト名が異なる https://example.com と http://example.com 別オリジン スキームが異なる https://example.com と https://example.com:8443 別オリジン ポート番号が異なる 本記事で扱う「クロスオリジン」とはこのオリジンが異なるWebサイト同士のアクセスを指します。 なお、後述するCORPヘッダの設定値には「サイト」という単位も登場します。 「サイト」はオリジンより広い単位で登録可能なドメイン（例：example.com）が同じであれば、サブドメインが異なっても同一サイトとみなされます。 例えば https://example.com と https://sub.example.com は「別オリジンだが同一サイト」という関係になります。 クロスオリジン分離とは クロスオリジン分離とは信頼できないクロスオリジンとの不要なデータ共有や相互参照を制限し、ブラウザ上でより安全な実行環境を実現する仕組みです。 クロスオリジン分離を実現することでSpectreをはじめとしたサイドチャネル攻撃のリスクを低減できるほか、後述するSharedArrayBufferなど一部の高度なブラウザ機能を利用できるようになります。 サイドチャネル攻撃とSpectre ・サイドチャネル攻撃とはプログラムの処理内容そのものではなく、処理にかかる時間やメモリの挙動といった「副次的に漏れ出る情報」を手がかりに本来知り得ない情報を推測する攻撃手法です。 ・Spectreはその代表例でCPUの投機的実行（先の処理を予測して先回りで実行し、高速化する仕組み）を悪用し、本来アクセスできないメモリ上の情報を推測して取得するサイドチャネル攻撃です。 これらの攻撃はブラウザ上で複数オリジンのデータが同じプロセスに同居していると成立しやすくなります。 そのため、オリジン同士を分離するクロスオリジン分離が対策として有効です。 クロスオリジン分離を必要とする代表的なブラウザ機能 以下のような機能は安全に利用するためにクロスオリジン分離を必要とします。 SharedArrayBuffer 複数スレッド間でメモリを共有できる機能 performance.measureUserAgentSpecificMemory() Webページが使用しているメモリ量を詳細に計測する機能 高精度タイマー（performance.now()など） マイクロ秒単位で処理時間を計測できる機能 WebAssembly Threads WebAssemblyによるマルチスレッド処理を実現する機能 これらの機能を安全に利用するためにはCOOPやCOEPを適切に設定し、クロスオリジン分離を実現する必要があります。 3つのヘッダの全体像 各ヘッダの詳細に入る前にまずCOEP・CORP・COOPの役割を俯瞰します。 3つのヘッダはそれぞれ異なる観点からクロスオリジンアクセスを制御します。 COEP：外部リソースを読み込む側の制御 怪しいものは読み込まない CORP：リソースを提供する側の制御 自分のものは勝手に使わせない COOP：他サイトとのウィンドウ関係の制御 他サイトとのつながりを切る それぞれ役割は異なりますが共通する目的は「信頼できないクロスオリジンとの不要な関わりを減らすこと」です。 これらを組み合わせることでクロスオリジン分離が実現され、より安全な実行環境を構築できます。 なお、クロスオリジン分離はCOOPとCOEPの両方を設定して初めて成立します（CORPはCOEPを補助する役割です）。 どちらか一方だけでは分離状態にはならない点に注意してください。 具体的な設定値は次章以降で各ヘッダごとに説明します。 以降で、各ヘッダの詳細を順に見ていきます。 COEPヘッダとは 概要 COEPヘッダは「利用が明示的に許可された外部リソースのみ読み込む」ためのヘッダです。 Webサイトでは画像やJavaScript、iframeなどの外部リソースを利用することがあります。 COEPヘッダを設定するとクロスオリジンリソースの取り扱いが制限され、利用が明示的に許可されていないリソースはブラウザによってブロックされます。 図1. COEPによるクロスオリジンリソースの読み込み制御 出典： web.dev「優れた機能のために『クロスオリジン分離』が必要な理由」 https://web.dev/articles/why-coop-coep Licensed under CC BY 4.0. 設定値は以下のとおりです。 require-corp：CORSまたはCORPで利用が許可されたリソースのみ許可 credentialless：認証情報を送信しない条件で一部のクロスオリジンリソースを許可 unsafe-none：制限なし（デフォルト） ※CORS（Cross-Origin Resource Sharing）とはあるオリジンのページから別オリジンのリソースへのアクセスをリソース提供側が許可する範囲で認める仕組みです。 効果 安全性が確認できない外部リソースの読み込みを防止する クロスオリジン分離を実現し、Spectre などのサイドチャネル攻撃のリスクを低減する CORPヘッダとは 概要 CORPヘッダは「自サイトのリソース利用範囲を制御する」ためのヘッダです。 例えば、自サイトで公開している画像やJavaScriptなどのリソースを意図しない外部サイトから利用されたくない場合に使用します。 CORPヘッダを設定することで自サイトのリソースがどのサイトから利用できるかを制御でき、外部サイトによる意図しない利用を防ぐことができます。 設定値は以下のとおりです。 same-origin：同一オリジンのみ許可 same-site：同一サイトのみ許可 cross-origin：すべてのオリジンからの利用を許可 効果 自サイトのリソース利用範囲を制御する リソースを提供する側からクロスオリジン分離を支援する COOPヘッダとは 概要 COOPヘッダは「他サイトとのウィンドウのつながりを切り離す」ためのヘッダです。 例えば、外部サイトが window.open() を利用して自サイトを開いた場合、通常は開いた側と開かれた側の間に関係が残り、開いた側のページは開かれたページのウィンドウを参照したり、ページ遷移を引き起こすことができます。 COOPヘッダを設定するとこの関係が分離され、外部サイトから自サイトのウィンドウを参照・操作できなくなります。 図2. COOPによるブラウジングコンテキストの分離 出典： web.dev「優れた機能のために『クロスオリジン分離』が必要な理由」 https://web.dev/articles/why-coop-coep Licensed under CC BY 4.0. ※ブラウジングコンテキストとはタブやウィンドウ、iframeなど、Webページが表示・実行される単位を指す用語です。 COOPはこの単位同士のつながりを制御します。 設定値は以下のとおりです。 same-origin：同一オリジン以外とのウィンドウ関係を分離する same-origin-allow-popups：自ページが開いたポップアップとのウィンドウ関係は維持し、それ以外は分離する noopener-allow-popups：ポップアップを開くこと自体は許可するが、開いたポップアップとのウィンドウ関係は分離する unsafe-none：制限なし（デフォルト） 効果 外部サイトとのウィンドウ関係を分離し、クロスオリジン間の不要な連携や影響を抑制する クロスオリジン分離の確認方法 クロスオリジン分離が有効になっているかはブラウザの開発者ツール（Console）で以下を実行することで確認できます。 self.crossOriginIsolated 実行結果が「true」の場合はクロスオリジン分離が有効です。 一方、「false」が表示された場合はCOOP（same-origin）とCOEP（require-corpなど）のいずれかが未設定であるか、読み込んでいるリソースがCORS/CORPの要件を満たしていないなどの理由でクロスオリジン分離が成立していない可能性があります。 対応は必須か COEP、CORP、COOPヘッダは未設定だからといって直ちに脆弱性となるわけではありません。 判断の軸は「クロスオリジン分離（COOP＋COEPの併用）が必要か」と「個々のヘッダによる保護が必要か」を分けて考えることです。 以下のような場合は設定を検討することが推奨されます。 SharedArrayBufferなどクロスオリジン分離を必要とする機能を利用する場合（COOPとCOEPの併用が必須） ブラウザセキュリティを強化したい場合 脆弱性検査やセキュリティ基準への対応が求められる場合 クロスオリジン分離を必要とする機能を使わないサイトではCOOPとCOEPを厳格に設定する必要は必ずしもありません。 ただし、その場合でもCOOP（same-origin）単体はタブナビングなどウィンドウ経由の攻撃対策として、CORP単体はリソースの意図しない外部利用の防止としてそれぞれ単独でも有効です。 このように「クロスオリジン分離としての対応」と「個別ヘッダによる保護」を切り分け、自サイトの要件に応じて対応範囲を決めることが望ましいでしょう。 Tips：COEP、CORP、COOP導入時の注意点 COEP、CORP、COOPはセキュリティを強化する一方で、既存システムへ適用する際には注意が必要です。 COEP適用時は外部リソースの動作に注意する COEPを有効にすると外部CDNから配信される画像、JavaScript、iframeなどが読み込めなくなる場合があります。 特に以下のようなリソースを利用している場合は事前の動作確認を推奨します。 CDN配信のJavaScript アクセス解析ツール 広告タグ 外部サービスが提供するiframe COOP適用時は外部サービス連携を確認する COOP（Cross-Origin-Opener-Policy）を有効にすると異なるオリジンのページとのウィンドウ関係が分離されます。 これにより、従来は利用できていたwindow.openerなどのウィンドウ間参照が制限され、異なるサイト間での情報の受け渡しや連携処理に影響を与える場合があります。 そのため、以下のような機能では動作に影響が発生する可能性があります。 OAuth認証 シングルサインオン（SSO） 決済サービス window.open() を利用する機能 例えば、認証サービスや決済サービスがポップアップウィンドウを開き、認証や決済完了後にwindow.openerを利用して元の画面へ結果を通知する実装の場合、COOPによってウィンドウ間の参照が切り離されることで正常に連携できなくなる可能性があります。 ポップアップとの連携が必要な場合は、影響範囲を十分に確認したうえでsame-origin-allow-popupsの利用も検討してください。 まとめ 本記事では脆弱性検査で検出されることが増えているCOEP、CORP、COOPヘッダについて紹介しました。 これらのヘッダはそれぞれ異なる観点からクロスオリジンアクセスを制御し、組み合わせることでクロスオリジン分離（Cross-Origin Isolation）を実現します。 その結果、Spectreをはじめとするサイドチャネル攻撃のリスクを低減できるほか、SharedArrayBufferなどの高度なブラウザ機能を利用できるようになります。 検査結果でCOEP、CORP、COOPヘッダの未設定を指摘された際は単なるHTTPヘッダ不足ではなく、現代ブラウザのセキュリティモデルへの対応状況を示す項目として捉えてください。 本記事がCOEP、CORP、COOPヘッダに対する理解を深める一助となれば幸いです。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @ogasawara.shota レビュー： @yahagi.ginpei1128 （ Shodo で執筆されました ）

自己紹介と参加理由 自己紹介 インターンシップに参加させていただいた田中夢乃です！ 大学ではプログラミングやネットワークなどの情報技術を学びながら、牡蠣の養殖現場をIoTで支えるプロジェクトにも取り組んでいます。 趣味はたくさんありますが、なかでも絵を描くことなど、自分の手で何かをつくり出すことが大好きです。   なぜサイオスのインターンシップを選んだのか 参加理由は大きく2点あります。 １つ目は 社員の方々の温かい人柄と、自由さと真面目さを兼ね備えた社風 に魅力を感じ 「サイオスをもっと知りたい」と思ったことです。 ２つ目は ハッカソン型開発や座談会など10日間の充実したプログラム内容です。 エンジニアの方と関わり実践的に手を動かすことで働くイメージを具体化し、様々な 企画への挑戦を通じて自身の強みや課題を発見したい と考え、参加を決意しました！ チームでのアプリ開発 成果物の紹介 私が所属したチームでは、大学生向けアプリケーション 「メタゼロ」 を制作しました。 メインターゲットに据えたのは、大学生活に加えて就活が始まり、タスク管理がより大変になる大学3年生、つまり私たち自身です。 私たちが着目したのは、タスクを探し、計画し、管理する作業に時間を取られ、本来大切にしたい「学ぶ時間」が削られてしまうという課題でした。この 「探す・計画する・管理する」時間を「メタ学習時間」と定義し 、 それを減らして本質的な学びの時間を増やすことを目標 に、「メタゼロ」の制作に取り組みました。 自分の役割 私が主に担当したのは、 UIのデザイン・実装と、キャラクターのデザイン・制作 です。本格的に取り組むのは今回が初めてでした。 自分でデザインしたものはメンバーにフィードバックをもらいながらブラッシュアップし、 そのまま実装も担当しました 。 ▲デザイン・実装した部分一部抜粋   そして一番の大仕事となったのが、 キャラクター制作 です。 きっかけは、開発序盤にメンバー全員でFigmaを使って画面設計を行おうとした際、 自分だけFigmaに入れないというトラブルが発生し、一時的にやることがなくなってしまった ことです。その空いた時間で趣味のイラスト制作を活かしてキャラクターを作ることにしました。 このハプニングから生まれたのが、アプリのマスコット 「ミツバチ」 です。 手書きでパーツ分けしたイラストを1コマ（約0.12秒）ごとに少しずつ動かし変形させてアニメーションを制作 し、通常・笑顔・喜ぶの3パターンのモーションとして実装しました。 ▲喜ぶミツバチちゃんの制作画面 ミツバチをモチーフにした理由は、 「本質的な学びの時間」というゴールを「花」に見立てたとき、「花（ゴール）までまっすぐ導く」というイメージがアプリのコンセプトと結びついたため です。また、蜂の巣のハニカム構造は理系らしいデザインとしてアプリの随所に取り入れ、世界観を生み出す助けにもなりました。 ミツバチちゃんはメンバーにもたくさん可愛がってもらえる存在になりました。 開発から成果発表までの道のり チームでは、必要な機能とワイヤーフレームを定めたあと、まずは 動作や機能面に絞って実装を進めました。 中間発表ではUI適用前で見た目は簡素な状態でしたが、そこで受けたフィードバックをもとに成果発表に向けてブラッシュアップを重ねました。 最後は 「できるところまで全力でやりきりたい」 という思いが重なり、準備が間に合わない事態も起こりましたが、 各自が担当部分を精一杯準備し、何とか本番を乗り切ることができました。 限られた時間で全力の作品を作り上げ、無事に発表を終えたときは 「やり切った」と達成感 を得られました。 プレゼンでは作品のミツバチも好評でうれしかったです。 また、他チームの発表を聞く中で、 アイディアや見せ方の工夫など多くの学びを得ることができました。 特にエンジニアの方々からのフィードバックでは、 アプリの完成度だけでなくプレゼンの構成や話し方までご指導 いただき、大変勉強になりました。 己の至らなさに悔しさも感じましたが、この経験を確実に自分の力にし、今後のプレゼンテーションに活かしていきます。 チーム開発を通じて気づいたこと リモート作業におけるコミュニケーション リモートだからこそ互いの反応が伝わりづらいと気づき、Meetの「リアクションボタン」機能を使うなど、 対面以上に明確に伝わるリアクション を心がけました。 また、簡単に画面共有ができるリモートならではの利点を活かし、進捗確認や言葉だけでは伝わりづらい説明の際には積極的に画面を共有しました。 同じ場所にいないからこそ、 「みんなで同じものを見る」という機会を自然と大事にでき、一体感が生まれていた ように思います。 チームの雰囲気と声掛けの重要性 開発序盤は、初対面の緊張から手探り状態でしたが、メンターの助言もあり日を追うごとに打ち解け、最後には 「もう一度このチームでやりたい」と言い合えるほど関係性が深まりました 。 互いの強みを頼り、声をかけ合って進めた空気感は、SIOS Valuesの「チームワーク」を体現していた と感じます。 特に、個人作業になりがちな場面でメンバーが「今どんな感じですか？」と適宜声をかけてくれたことが非常に心強く、 仲間を気にかける大切さに気づかされました。 進捗確認による安心感や全体の見通しの良さを実感できたため、 今度は私自身から周囲へ能動的に声をかけていきたいです。 AI開発で感じた新しいエンジニア像 今回初めてClaudeを用いて開発を行いましたが、そのスピードに驚くばかりで、使いこなすところまでは至らなかったように感じます。 AI自身がファイルを操作し設定確認まで行ってくれる馬力は桁違いで、ついていけるか不安に感じる一方、 コードをより感覚的に書けるようになったとも感じ、新しいエンジニア像にワクワクしました。 Claude開発でのリアルな失敗談と、その乗り越え方 Claudeを用いた開発では、圧倒的な処理能力と便利さを実感した一方で、生成時の待機時間やトークン上限による中断といった失敗を通じ、運用工夫の重要性を学びました。 当初は待ち時間に手が止まる場面もありましたが、 そういった時こそ人とAIがやるべき作業を明確に切り分ける計画性が不可欠 だと気づきました。 メンターから教わった 「二窓運用」 により、一方の処理中に別の指示を準備することで成果を伸ばせる一方、トークン消費速度が早まるという新たな課題にも直面しました。開発前半は試行錯誤が続きましたが、後半にはチーム全体で意識が揃い、 「AIの修正中に人間がコード検証を進める」といった計画的な連携が可能 になりました。 コード記述の負担が減る一方で、 「AIの使い方そのものを模索する思考負荷」が生じるという新たな発見 もありました。 失敗を重ねながら手探りでチームのペースをつかみ、最適な協働方法を見出していく過程は、大変ながらも非常に楽しい経験となりました。 インターンを通しての最大の収穫 10日間のインターンシップを通して、実際に社員の方々と関わりながら開発を体験できたことで、 エンジニアとして働くイメージの解像度が一気に上がった と感じます。 お客様と向き合うリアルな体験談を伺えたことや、AIを活用した開発という新しい経験が加わったことで、 自分が働く姿をより鮮明にイメージできるようになりました 。 また、サイオスと出会って最初に感じた 「こんな環境で働きたい」「こんな人たちと働きたい」という感覚を、より確かなものにできた と感じています。 お話しした社員の皆さんは気さくな方ばかりで、もっとお話を聞きたいと思えるようなあたたかな雰囲気を、身をもって感じることができました。 これからインターンを受ける後輩へ向けたアドバイスや応援の一言！ サイオスのインターンシップに参加して、自信も課題も含めてたくさんの収穫がありました。 参加して本当によかったと思っています。 これから参加される方は、ぜひ 失敗を気にせず思い切り挑戦してみてください 。サイオスの皆さんは、きっと全力で受け止めてくれます！ 今後の目標 ここで得た経験や学びを忘れずに、 働く上で自分が何を大事にしたいかを改めて考えていきたい と思います。 また、社会人になってからも、チーム開発を通じて気づいた自身の課題や、メンバーの尊敬すべき部分を思い出しながら、 技術面・チームワークの両面で貢献できる人になりたい と考えています！ 最後になりますが、出会った社員の皆様には本当に良くしていただき、感謝の気持ちでいっぱいです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post トラブルからミツバチ誕生？！デザイン✕AI開発で挑んだ10日間 first appeared on SIOS Tech Lab .

こんにちは、ソフトクリエイトのサトキチです。 オンプレミス環境からキャリアをスタートし、現在はMicrosoft 365を中心としたクラウドサービスに携わっています。 社内システムを管理していると、Windowsやネットワーク機器、業務アプリケーションなど、さまざまな製品の脆弱性情報が届きます。