ウェブアプリケーションセキュリティ 第2版

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

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

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

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

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

10年前、ほとんどのWebアプリケーションはサーバ側のフレームワークを使って構築され、HTML/JS/CSSページをレンダリングしてクライアントに送信していた。更新が必要になると、クライアントはサーバに別のページをリクエストし、HTTPでレンダリングしてもらうだけだった。その後まもなく、WebアプリケーションはAJAX（非同期JavaScriptとXML）の台頭とともにHTTPを頻繁に利用するようになり、JavaScriptを使ってページセッション内からネットワークリクエストを行えるようになった。

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

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

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

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

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

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