Web アプリケーションセキュリティ

第3章 最新のウェブアプリケーションの構造

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

リコン目的のウェブ・アプリケーションを効果的に評価する前に、多くのウェブ・アプリケーションが依存関係として共有する共通技術について理解を深めることが最善である。これらの依存関係は、JavaScript のヘルパーライブラリや定義済みの CSS モジュールから、ウェブサーバやオペレーティングシステムにまで及ぶ。アプリケーションスタックにおけるこれらの依存関係の役割とその一般的な実装を理解することで、それらを素早く特定し、誤った設定を探すことが非常に容易になる。

最新のウェブアプリケーションとレガシーアプリケーション

今日のウェブ アプリケーションは、10年前には存在しなかったテクノロジーの上に構築されていることが多い。ウェブアプリケーションを構築するために利用可能なツールは、その間に非常に進歩したため、今日では全く別の特殊化のように思えることもある。

10年前、ほとんどのWebアプリケーションはサーバ側のフレームワークを使って構築され、HTML/JS/CSSページをレンダリングしてクライアントに送信していた。更新が必要になると、クライアントは単純にサーバに別のページをリクエストし、HTTPでレンダリングされ、送信される。

その直後、Ajax（非同期JavaScriptとXML）の台頭により、WebアプリケーションはHTTPを頻繁に利用するようになり、JavaScriptを使ってページセッション内からNetworkリクエストを行えるようになった。

今日、多くのアプリケーションは、単一のモノリシックアプリケーションではなく、ネットワークプロトコルを介して通信する2つ以上のアプリケーションとして、より適切に表現されている。これは、今日のウェブ・アプリケーションと10年前のウェブ・アプリケーションとの間の、1つの大きなアーキテクチャの違いである。

今日のウェブ・アプリケーションは、REST API（Representational State Transfer）で接続された複数のアプリケーションで構成されていることが多い。これらのAPIはステートレスで、あるアプリケーションから別のアプリケーションへのリクエストを満たすためだけに存在する。つまり、APIは実際にはリクエスト元の情報を保存していない。

今日のクライアント（UI）アプリケーションの多くは、より伝統的なデスクトップアプリケーションに近い方法でブラウザ上で実行される。これらのクライアント・アプリケーションは、独自のライフサイクル・ループを管理し、独自のデータを要求し、初期化完了後にページのリロードを必要としない。

ウェブブラウザにデプロイされたスタンドアロンアプリケーションが、多数のサーバと通信することは珍しくない。ユーザがログインできる画像ホスティング・アプリケーションを考えてみよう。おそらく、あるURLには特殊化されたホスティング/配信サーバがあり、データベースとログインを管理するための別のURLがあるだろう。

今日のアプリケーションは、実際には多くの別々の、しかし共生しているアプリケーションが一体となって動作していることが多いと言っていいだろう。これは、より明確に定義されたネットワーク・プロトコルとAPIアーキテクチャ・パターンの開発に起因している。

現代の平均的なウェブ・アプリケーションは、おそらく以下のテクノロジーのいくつかを利用している： ...