シングルページ アプリケーション (SPA) のセキュリティは Web サイトと同じように機能しない

シングルページ アプリケーション (SPA) は、デジタル データ配信と顧客エンゲージメントのための開発が簡単なインターフェイスとして急速に強力な足場を築いています。

シングルページ アプリケーション (SPA) は、開発が容易であり、魅力的なユーザー エクスペリエンスを提供できるため、ますます人気が高まっています。ただし、SPA には特有のセキュリティ上の課題もあります。この記事では、SPA を保護する難しさを探り、トークン ハンドラー パターンとして知られる有望な解決策について説明します。

従来のウェブサイトには、HTML とデータを提供する単一のバックエンドがあります。ユーザー認証は通常、ネットワーク ファイアウォールで保護されているこのバックエンド サーバーで行われます。ただし、SPA は API を介して複数のマイクロサービスに接続されており、より分散化されたアーキテクチャが作成されます。この設定は SPA に軽量な利点をもたらしますが、重大なセキュリティ リスクももたらします。

主な課題の 1 つは、ユーザー認証がネットワーク ファイアウォールの背後にある保護されたサーバーで行われるのではなく、ブラウザーで行われることが多いことです。このため、SPA は、クロスサイト スクリプティング (XSS) 資格情報の盗難など、幅広い種類のサイバー攻撃に対して脆弱になります。この攻撃方法では、悪意のある攻撃者が、アクセス トークンとユーザー資格情報を盗むことができるコードをブラウザーに挿入し、最終的に貴重なデータやシステムへの不正アクセスを許可する可能性があります。

もう 1 つの課題は、通常は API を使用してアプリケーションに接続されているサードパーティ データへの多数の依存関係から発生します。大量のサードパーティ接続は 2 つの問題を引き起こす可能性があります。

まず、開発者は、他の専門家や組織が作成した API に組み込まれているセキュリティを制御できません。これにより、開発者の知らないうちにアプリケーションに脆弱性が導入される可能性があります。

第 2 に、この複雑で多様な環境でのプログラミングは、大量の詳細なカスタマイズされたコードと入力設定が関係するため、退屈になる可能性があります。重要な手順を見逃して、知らず知らずのうちにセキュリティ上のギャップが生じてしまう可能性があります。さらに、環境が成長し、時間の経過とともに変化するビジネス需要に適応するにつれて、隠れたセキュリティ リスクが発生する可能性があります。

課題をさらに説明するために、Web サイトと SPA を保護するための設定を比較してみましょう。

Web サイトを保護する場合、開発者は Cookie ベースのセッションを使用して、ユーザーに Web アプリケーションへのアクセスを許可できます。フロントエンド Web サイト クライアントはブラウザ上に Cookie を保存し、ユーザー アクセス リクエストごとに単一のバックエンド データ サーバーに送信されます。認可の決定はストレージに保存されたセッション データに基づいて行われるため、ユーザー アクセスはネットワーク ファイアウォールの内側で安全に保たれます。

シングルページ アプリケーションには専用のバックエンドがないため、このセットアップは SPA では実行できません。コンテンツ配信ネットワーク (CDN) は、多くの場合、静的ファイルを通じてコードを SPA に提供します。これらのファイルは、アプリケーションへの API 呼び出しを通じて返されます。 SPA 構成では、バックエンド データ ストレージがないため、ユーザーのセッションを Cookie に保存できません。代わりに、アクセス トークンを使用して、認証されたユーザーに代わって API を呼び出すことができます。

SPAのセキュリティ脆弱性

SPA のセキュリティの課題は、ブラウザベースの認証が幅広い種類のサイバー攻撃に対して脆弱であるという事実にかかっています。脅威の種類の 1 つは、クロスサイト スクリプティング (XSS) 資格情報の盗難です。この攻撃手法では、悪意のある攻撃者が、アクセス トークンとユーザー認証情報を盗むことができるコードをブラウザーに挿入し、貴重なデータとシステムへの不正アクセスを取得します。

XSS は一般的な脆弱性ですが、開発者が防御する必要があるのは XSS だけではありません。問題をさらに難しくしているのは、1 つの脆弱性を修正すると新たな脆弱性が発生することが多く、そのため SPA の保護は目標を変える終わりのないゲームになります。たとえば、OAuth フローを使用して、セッション Cookie の代わりに OAuth トークンでユーザーまたは API アクセスを認証することは、XSS 攻撃を軽減する良い方法のように思えます。

ただし、これらのトークンがローカル ストレージに保存されている場合、攻撃者は簡単にローカル ストレージやセッション ストレージにアクセスしてトークンを窃取できます。トークンを更新できる場合、ユーザーセッションが終了した後でも攻撃者がアクセスできるため、問題はさらに悪化します。

セキュリティ修正に伴う可能性のある意図しない問題のもう 1 つの例は、強力なセキュリティ ポリシーをコンテンツ セキュリティ ポリシー (CSP) ヘッダーに組み込むことです。これによりセキュリティ制御の層が追加される可能性がありますが、一部のソースではコンテンツ セキュリティ ポリシーを開いて無効にできる場合があります。

結論としては、データやシステムへの不正アクセスや悪意のあるアクセスから防御するという点では、ブラウザは敵対的な環境であるということです。セキュリティ対策には、1 つの攻撃ベクトルを遮断しても別の攻撃ベクトルへの道が開かれないようにするため、慎重なテストと継続的な警戒が必要です。

Cookieとトークンの両方の使用

悪意のある行為者からユーザー認証を保護するために最近開発された SPA を保護する方法の 1 つは、Web サイトの Cookie セキュリティとアクセス トークンを統合するトークン ハンドラー パターンです。ブラウザーから認証を削除し、同一サイト Cookie とトークンを使用してバックエンド対フロントエンド (BFF) 構成を活用するトークン ハンドラー アーキテクチャを実装することで、組織はセキュリティを犠牲にすることなく SPA の軽量な側面から恩恵を受けることができます。

この設定では、バックエンド コンポーネントとしてホストされる OAuth エージェントが SPA と認可サーバーの間に配置されます。 OAuth エージェントは SPA の OAuth フローを処理し、SPA にトークンが発行される代わりに、SPA がバックエンド API およびマイクロサービスへのアクセスを取得するために使用できる安全な HTTP 専用 Cookie が発行されます。

高性能 API ゲートウェイでホストされる OAuth プロキシ

以上がシングルページ アプリケーション (SPA) のセキュリティは Web サイトと同じように機能しないの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。