フロントエンドセキュリティの強化：コンテンツセキュリティポリシーとCORS

今日の相互接続されたデジタル環境において、フロントエンドのセキュリティは最重要です。ウェブアプリケーションはますます巧妙な攻撃の標的となっており、堅牢なセキュリティ対策が不可欠です。セキュアなフロントエンドアーキテクチャの2つの重要な要素が、コンテンツセキュリティポリシー(CSP)とオリジン間リソース共有(CORS)です。この包括的なガイドでは、これらの技術を深く掘り下げ、ウェブアプリケーションを現代の脅威から強化するための実践的な例と実用的な洞察を提供します。

コンテンツセキュリティポリシー(CSP)とは？

コンテンツセキュリティポリシー(CSP)は、クロスサイトスクリプティング(XSS)やデータインジェクション攻撃といった特定の種類の攻撃を検出し、緩和するのに役立つ追加のセキュリティ層です。CSPは、ウェブサーバーがブラウザにContent-Security-Policy HTTPレスポンスヘッダーを送信することで実装されます。このヘッダーは、ブラウザがリソースを読み込むことを許可されているソースのホワイトリストを定義します。ブラウザが読み込めるコンテンツのソースを制限することで、CSPは攻撃者がウェブサイトに悪意のあるコードを注入するのを大幅に困難にします。

CSPの仕組み

CSPは、承認されたソースからのみリソース(例：スクリプト、スタイルシート、画像、フォント)を読み込むようブラウザに指示することで機能します。これらのソースは、CSPヘッダー内でディレクティブを使用して指定されます。ブラウザが明示的に許可されていないソースからリソースを読み込もうとすると、そのリクエストをブロックし、違反を報告します。

CSPディレクティブ：包括的概要

CSPディレクティブは、特定のソースから読み込むことができるリソースの種類を制御します。以下に、最も重要なディレクティブのいくつかを紹介します：

• default-src: すべてのコンテンツタイプのデフォルトソースを指定します。これは、より具体的な他のディレクティブが存在しない場合に適用されるフォールバックディレクティブです。
• script-src: スクリプトを読み込めるソースを指定します。これはXSS攻撃を防ぐ上で非常に重要です。
• style-src: スタイルシートを読み込めるソースを指定します。
• img-src: 画像を読み込めるソースを指定します。
• font-src: フォントを読み込めるソースを指定します。
• media-src: 音声や動画を読み込めるソースを指定します。
• object-src: プラグイン(例：Flash)を読み込めるソースを指定します。これは固有のセキュリティリスクのため、プラグインを完全に無効にするためにしばしば 'none' に設定されます。
• frame-src: フレーム(例：<iframe>)を読み込めるソースを指定します。
• connect-src: ユーザーエージェントがXMLHttpRequest、WebSocket、EventSourceなどのスクリプトインターフェースを使用して接続できるURLを指定します。
• base-uri: ドキュメントの<base>要素で使用できるURLを指定します。
• form-action: フォームの送信先となるURLを指定します。
• upgrade-insecure-requests: 安全でないリクエスト(HTTP)を安全なリクエスト(HTTPS)に自動的にアップグレードするようユーザーエージェントに指示します。
• report-uri: ブラウザがCSP違反に関するレポートを送信すべきURLを指定します。このディレクティブは`report-to`を優先するため非推奨です。
• report-to: `Report-To`ヘッダーで定義されたレポーティンググループ名を指定し、ブラウザがCSP違反に関するレポートをそこに送信するようにします。

CSPソースリストキーワード

CSPディレクティブ内では、ソースリストキーワードを使用して許可されたソースを定義できます。以下は一般的なキーワードの一部です：

• 'self': ドキュメントと同じオリジン(スキームとホスト)からのリソースを許可します。
• 'none': すべてのソースからのリソースを不許可にします。
• 'unsafe-inline': インラインスクリプトやスタイルの使用を許可します(例：<script>タグやstyle属性)。XSSに対するCSPの保護を大幅に弱めるため、細心の注意を払って使用してください。
• 'unsafe-eval': eval()やFunction()のような動的コード評価関数の使用を許可します。重大なセキュリティリスクをもたらすため、細心の注意を払って使用してください。
• 'unsafe-hashes': 指定されたハッシュに一致する特定のインラインイベントハンドラや<style>タグを許可します。ブラウザのサポートが必要です。注意して使用してください。
• 'strict-dynamic': nonceまたはハッシュを伴うことでマークアップ内に存在するスクリプトに明示的に与えられた信頼が、そのルートスクリプトによって読み込まれるすべてのスクリプトに伝播されるべきであることを指定します。
• data: data: URIを許可します(例：base64でエンコードされたインライン画像)。注意して使用してください。
• https:: 任意のドメインからHTTPS経由でリソースを読み込むことを許可します。
• [hostname]: 特定のドメインからのリソースを許可します(例：example.com)。ポート番号を指定することも可能です(例：example.com:8080)。
• [scheme]://[hostname]:[port]: 完全修飾URIで、指定されたスキーム、ホスト、ポートからのリソースを許可します。

CSPの実践例

CSPヘッダーの実践的な例をいくつか見てみましょう：

例1：'self'を使用した基本的なCSP

このポリシーは、同一オリジンからのリソースのみを許可します：

            Content-Security-Policy: default-src 'self'
            

              
                Copy
              
            
          

例2：特定のドメインからのスクリプトを許可する

このポリシーは、自ドメインと信頼できるCDNからのスクリプトを許可します：

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com
            

              
                Copy
              
            
          

例3：インラインスクリプトとスタイルを無効にする

このポリシーはインラインスクリプトとスタイルを許可せず、XSSに対する強力な防御となります：

            Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'
            

              
                Copy
              
            
          

重要：インラインスクリプトを無効にするには、インラインスクリプトを外部ファイルに移動するようにHTMLをリファクタリングする必要があります。

例4：インラインスクリプトにノンスを使用する

インラインスクリプトを使用する必要がある場合は、ノンス(暗号学的にランダムな、一度だけ使用されるトークン)を使用して特定のインラインスクリプトブロックをホワイトリストに登録します。これは'unsafe-inline'よりも安全です。サーバーはリクエストごとに一意のノンスを生成し、それをCSPヘッダーと<script>タグの両方に含める必要があります。

            Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0mN0nc3'; style-src 'self'
            

              
                Copy
              
            
          

            <script nonce="r4nd0mN0nc3"> console.log('Inline script'); </script>
            

              
                Copy
              
            
          

注：リクエストごとに新しいノンスを生成することを忘れないでください。ノンスを再利用してはいけません！

例5：インラインスタイルにハッシュを使用する

ノンスと同様に、ハッシュを使用して特定のインライン<style>ブロックをホワイトリストに登録できます。これは、スタイルコンテンツのSHA256、SHA384、またはSHA512ハッシュを生成することによって行われます。

            Content-Security-Policy: default-src 'self'; style-src 'sha256-HASHEDSTYLES'
            

              
                Copy
              
            
          

            <style sha256="HASHEDSTYLES"> body { background-color: #f0f0f0; } </style>
            

              
                Copy
              
            
          

注：ハッシュはノンスよりも柔軟性が低く、スタイルコンテンツが少しでも変更されるとハッシュは無効になります。

例6：CSP違反を報告する

CSP違反を監視するには、report-uriまたはreport-toディレクティブを使用します：

            Content-Security-Policy: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

また、Report-Toヘッダーを設定する必要もあります。Report-Toヘッダーは1つ以上のレポーティンググループを定義し、レポートをどこに、どのように送信するかを指定します。

            Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://example.com/csp-report"}]}
            

              
                Copy
              
            
          

CSPのテストとデプロイ

CSPを実装するには、慎重な計画とテストが必要です。まず制限の厳しいポリシーから始め、必要に応じて徐々に緩めていきます。Content-Security-Policy-Report-Onlyヘッダーを使用して、リソースをブロックせずにポリシーをテストします。このヘッダーはポリシーを強制せずに違反を報告するため、本番環境にデプロイする前に問題を特定して修正することができます。

            Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint;
            

              
                Copy
              
            
          

ブラウザによって生成されたレポートを分析して違反を特定し、それに応じてポリシーを調整します。ポリシーが正しく機能していると確信できたら、Content-Security-Policyヘッダーを使用してデプロイします。

CSPのベストプラクティス

• default-srcから始める：常にdefault-srcを定義して、ベースラインとなるポリシーを確立します。
• 具体的に指定する：特定のディレクティブとソースリストキーワードを使用して、ポリシーの範囲を限定します。
• 'unsafe-inline'と'unsafe-eval'を避ける：これらのキーワードはCSPを大幅に弱体化させるため、可能な限り避けるべきです。
• インラインスクリプトとスタイルにはノンスまたはハッシュを使用する：インラインスクリプトやスタイルを使用する必要がある場合は、ノンスまたはハッシュを使用して特定のコードブロックをホワイトリストに登録します。
• CSP違反を監視する：report-uriまたはreport-toディレクティブを使用してCSP違反を監視し、それに応じてポリシーを調整します。
• 徹底的にテストする：Content-Security-Policy-Report-Onlyヘッダーを使用して、本番環境にデプロイする前にポリシーをテストします。
• 反復と改善：CSPは一度設定すれば終わりではありません。アプリケーションや脅威の状況の変化に適応するために、ポリシーを継続的に監視し、改善してください。

オリジン間リソース共有(CORS)とは？

オリジン間リソース共有(CORS)は、あるオリジン(ドメイン)のウェブページが、異なるオリジンのリソースにアクセスできるようにする仕組みです。デフォルトでは、ブラウザは同一オリジンポリシーを強制し、スクリプトがそのスクリプトの生成元とは異なるオリジンにリクエストを行うことを防ぎます。CORSは、この制限を選択的に緩和する方法を提供し、正当なオリジン間リクエストを許可しつつ、悪意のある攻撃から保護します。

同一オリジンポリシーの理解

同一オリジンポリシーは、あるウェブサイトの悪意のあるスクリプトが別のウェブサイトの機密データにアクセスするのを防ぐ基本的なセキュリティメカニズムです。オリジンはスキーム(プロトコル)、ホスト(ドメイン)、ポートによって定義されます。2つのURLが同じオリジンを持つのは、スキーム、ホスト、ポートがすべて同じ場合のみです。

例：

• https://www.example.com/app1/index.html と https://www.example.com/app2/index.html は同じオリジンです。
• https://www.example.com/index.html と http://www.example.com/index.html は異なるオリジンです (スキームが異なる)。
• https://www.example.com/index.html と https://sub.example.com/index.html は異なるオリジンです (ホストが異なる)。
• https://www.example.com:8080/index.html と https://www.example.com:80/index.html は異なるオリジンです (ポートが異なる)。

CORSの仕組み

ウェブページがオリジン間リクエストを行うと、ブラウザはまずサーバーに「プリフライト」リクエストを送信します。プリフライトリクエストはHTTP OPTIONSメソッドを使用し、実際のリクエストが使用するHTTPメソッドとヘッダーを示すヘッダーを含みます。サーバーはその後、オリジン間リクエストが許可されているかどうかを示すヘッダーで応答します。

サーバーがリクエストを許可する場合、レスポンスにAccess-Control-Allow-Originヘッダーを含めます。このヘッダーは、リソースへのアクセスが許可されているオリジンを指定します。ブラウザはその後、実際のリクエストを続行します。サーバーがリクエストを許可しない場合、Access-Control-Allow-Originヘッダーは含められず、ブラウザはリクエストをブロックします。

CORSヘッダー：詳細な解説

CORSは、ブラウザとサーバー間の通信にHTTPヘッダーを利用します。主要なCORSヘッダーは以下の通りです：

• Access-Control-Allow-Origin: リソースへのアクセスが許可されているオリジンを指定します。このヘッダーには特定のオリジン(例：https://www.example.com)、ワイルドカード(*)、またはnullを含めることができます。*を使用すると任意のオリジンからのリクエストが許可されますが、セキュリティ上の理由から一般的には推奨されません。`null`の使用は、リソースが`file://`プロトコルやデータURIを使用して取得された場合などの「不透明なレスポンス」にのみ適しています。
• Access-Control-Allow-Methods: オリジン間リクエストで許可されるHTTPメソッドを指定します(例：GET, POST, PUT, DELETE)。
• Access-Control-Allow-Headers: オリジン間リクエストで許可されるHTTPヘッダーを指定します。これはカスタムヘッダーを扱う上で重要です。
• Access-Control-Allow-Credentials: ブラウザがオリジン間リクエストにクレデンシャル(例：クッキー、認証ヘッダー)を含めるべきかどうかを示します。クレデンシャルを許可するには、このヘッダーをtrueに設定する必要があります。
• Access-Control-Expose-Headers: クライアントに公開できるヘッダーを指定します。デフォルトでは、限られたヘッダーセットのみが公開されます。
• Access-Control-Max-Age: ブラウザがプリフライトリクエストをキャッシュできる最大時間(秒単位)を指定します。
• Origin: これはリクエストのオリジンを示すためにブラウザから送信されるリクエストヘッダーです。
• Vary: 一般的なHTTPヘッダーですが、CORSにとって重要です。`Access-Control-Allow-Origin`が動的に生成される場合、レスポンスが`Origin`リクエストヘッダーに基づいて変化することをキャッシュメカニズムに指示するために、レスポンスに`Vary: Origin`ヘッダーを含めるべきです。

CORSの実践例

CORS設定の実践的な例をいくつか見てみましょう：

例1：特定のオリジンからのリクエストを許可する

この設定はhttps://www.example.comからのリクエストのみを許可します：

            Access-Control-Allow-Origin: https://www.example.com
            

              
                Copy
              
            
          

例2：任意のオリジンからのリクエストを許可する(非推奨)

この設定は任意のオリジンからのリクエストを許可します。セキュリティリスクをもたらす可能性があるため、注意して使用してください：

            Access-Control-Allow-Origin: *
            

              
                Copy
              
            
          

例3：特定のメソッドとヘッダーを許可する

この設定はGET、POST、PUTメソッド、およびContent-TypeとAuthorizationヘッダーを許可します：

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

例4：クレデンシャルを許可する

クレデンシャル(例：クッキー)を許可するには、Access-Control-Allow-Credentialsをtrueに設定し、特定のオリジンを指定する必要があります(クレデンシャルを許可する場合、*は使用できません)：

            Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Credentials: true
            

              
                Copy
              
            
          

また、JavaScriptのfetch/XMLHttpRequestリクエストでcredentials: 'include'を設定する必要もあります。

            fetch('https://api.example.com/data', {
  credentials: 'include'
})
            

              
                Copy
              
            
          

CORSプリフライトリクエスト

特定の種類のオリジン間リクエスト(例：カスタムヘッダーを持つリクエストや、GET、HEAD、POST(Content-Typeがapplication/x-www-form-urlencoded、multipart/form-data、text/plainの場合)以外のメソッドを持つリクエスト)に対して、ブラウザはOPTIONSメソッドを使用してプリフライトリクエストを送信します。サーバーは、実際のリクエストが許可されているかどうかを示すために、適切なCORSヘッダーでプリフライトリクエストに応答する必要があります。

プリフライトリクエストとレスポンスの例です：

プリフライトリクエスト (OPTIONS):

            OPTIONS /data HTTP/1.1
Origin: https://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization
            

              
                Copy
              
            
          

プリフライトレスポンス (200 OK):

            HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400
            

              
                Copy
              
            
          

Access-Control-Max-Ageヘッダーは、ブラウザがプリフライトレスポンスをキャッシュできる期間を指定し、プリフライトリクエストの数を減らします。

CORSとJSONP

JSON with Padding (JSONP)は、同一オリジンポリシーを回避するための古い技術です。しかし、JSONPには重大なセキュリティリスクがあるため、CORSを優先して避けるべきです。JSONPはページに<script>タグを注入することに依存しており、これにより任意のコードが実行される可能性があります。CORSは、オリジン間リクエストを処理するためのより安全で柔軟な方法を提供します。

CORSのベストプラクティス

• *の使用を避ける：Access-Control-Allow-Originヘッダーでワイルドカード(*)を使用すると、任意のオリジンからのリクエストが許可されてしまうため避けてください。代わりに、リソースへのアクセスが許可されている特定のオリジンを指定します。
• メソッドとヘッダーを具体的に指定する：Access-Control-Allow-MethodsとAccess-Control-Allow-Headersヘッダーで許可されるHTTPメソッドとヘッダーを正確に指定します。
• Access-Control-Allow-Credentialsは慎重に使用する：オリジン間リクエストでクレデンシャル(例：クッキー)を許可する必要がある場合にのみAccess-Control-Allow-Credentialsを有効にします。クレデンシャルを許可することのセキュリティ上の意味を認識してください。
• プリフライトリクエストを保護する：サーバーがプリフライトリクエストを適切に処理し、正しいCORSヘッダーを返すことを確認してください。
• HTTPSを使用する：オリジンとクロスオリジンでアクセスするリソースの両方で常にHTTPSを使用してください。これは中間者攻撃から保護するのに役立ちます。
• Vary: Origin: `Access-Control-Allow-Origin`ヘッダーを動的に生成している場合は、キャッシュの問題を防ぐために常に`Vary: Origin`ヘッダーを含めてください。

実践におけるCSPとCORS：組み合わせたアプローチ

CSPとCORSはどちらもセキュリティ上の懸念に対処しますが、異なるレイヤーで動作し、相互に補完的な保護を提供します。CSPはブラウザが悪意のあるコンテンツを読み込むのを防ぐことに焦点を当て、CORSはどのオリジンがサーバー上のリソースにアクセスできるかを制御することに焦点を当てています。

CSPとCORSを組み合わせることで、ウェブアプリケーションのセキュリティ体制をより堅牢にすることができます。たとえば、CSPを使用してスクリプトが読み込まれるソースを制限し、CORSを使用してどのオリジンがAPIエンドポイントにアクセスできるかを制御できます。

例：CSPとCORSでAPIを保護する

https://api.example.comでホストされているAPIをhttps://www.example.comからのみアクセス可能にしたいとします。サーバーが以下のヘッダーを返すように設定できます：

APIレスポンスヘッダー (https://api.example.com):

            Access-Control-Allow-Origin: https://www.example.com
Content-Type: application/json
            

              
                Copy
              
            
          

そして、ウェブサイト(https://www.example.com)が以下のCSPヘッダーを使用するように設定できます：

ウェブサイトCSPヘッダー (https://www.example.com):

            Content-Security-Policy: default-src 'self'; script-src 'self'; connect-src 'self' https://api.example.com;
            

              
                Copy
              
            
          

このCSPポリシーにより、ウェブサイトはスクリプトを読み込み、APIに接続できますが、他のドメインからスクリプトを読み込んだり接続したりすることはできなくなります。

結論

コンテンツセキュリティポリシー(CSP)とオリジン間リソース共有(CORS)は、フロントエンドアプリケーションのセキュリティを強化するための不可欠なツールです。CSPとCORSを慎重に設定することで、XSS攻撃、データインジェクション攻撃、その他のセキュリティ脆弱性のリスクを大幅に削減できます。制限の厳しいポリシーから始め、徹底的にテストし、アプリケーションと進化する脅威の状況の変化に適応するために設定を継続的に監視および改善することを忘れないでください。フロントエンドのセキュリティを優先することで、ユーザーを保護し、今日のますます複雑化するデジタル世界でウェブアプリケーションの完全性を確保することができます。