この記事は「ECMAScript2015/ES6特集」の第3回目です。この特集ではJavaScriptの次世代仕様であるECMAScript 2015（ECMAScript 6）を取り上げ、歴史や経緯から追加された機能や文法の詳細など、複数回に渡って解説していきます。

ここではECMAScriptの新仕様を先取りできるトランスパイラ、Babelの紹介を行います。

Babelとは

Babelとは、2014/9から開発が始まっているECMAScriptコンパイラです。

機能としては、ECMAScript2015 (ES6)やECMAScript7などで書かれたソースコードを一般的なブラウザがサポートしているECMAScript5の形式に出力することができます。

const obj = (() => {
  return {
    method() {
      alert('Hello Babel!');
    }
  };
})();

'use strict';

var obj = (function () {
  return {
    method: function method() {
      alert('Hello Babel!');
    }
  };
})();

Babelは最低限の機能をIE8以降で、フル機能をIE10以降でサポートします。
（実際にはIE9以降から使用することを推奨します）

当初Babelは6to5と呼ばれていましたが、ECMAScript7の仕様なども取り込むようになったため、バージョンを想定しないBabelという名前に変更されました。

Babelの特徴

Babelと同じように「トランスパイルすることでJavaScriptのコードを出力する」ツールにはTypeScriptやCoffeeScriptなどがあります。

それらと比較するとBabelは「ECMAScript標準仕様をベースにしている(*)」という特徴があります。

(*) 実際にはJSXもサポートしているため、必ずしもECMAScript標準仕様のみをサポートしているわけではありません。

このため、「いずれ標準実装される仕様を先取りできる」、「Babel自体が廃れても同じような標準仕様を扱うツールがあれば乗り換えできる」といった利点があります。

簡単に始める方法

それでは早速Babelを使ってみましょう。

お手軽に始める場合、Babelの公式サイトで公開されているオンライン上のトランスパイルサービスが便利でしょう。

これは左側にコードを書くとトランスパイルした結果を右側に出力してくれます。

もちろんこのまま開発を行うのは難しいため、実際には手元にツールをインストールして使うことになります。

Babelのインストール

Babelはnpm経由で以下のようにインストールします。

$ npm install --global babel

これでbabelコマンドが使用できるようになりました。

CLIを使った変換方法

それではまずはbabelコマンド経由で変換してみましょう。

babelコマンドでは以下のようにファイル名を引数に与えるか、標準入力にソースを渡すことによって標準出力へ変換結果を出力します。

$ cat sample.js () => {} $ babel sample.js "use strict";

$

この方法でも変換はできますが、実際の現場では次で紹介するような別のコマンド経由で変換されることが一般的です。

gulpを使った変換方法

では次にgulpを使った変換方法を紹介します。

gulpを使って変換するためには、gulpとBabelを繋げるためのgulp-babelというパッケージをインストールします。

$ npm install --global gulp $ npm install --save-dev gulp-babel

それでは変換してみましょう。

まずgulpfile.jsに以下のように記述します。

var gulp = require('gulp');
var babel = require('gulp-babel');
 
gulp.task('default', function () {
    return gulp.src(['src/*.js', 'src/**/*.js'])
        .pipe(babel())
        .pipe(gulp.dest('dist'));
});

この状態でgulpコマンドを実行することで、src/以下のjsファイルをBabelで変換してdist以下に書き出すことができます。

gruntを使った変換方法

次はgruntを使った変換方法を紹介します。

gruntを使って変換するためには、gulpの場合と同様にgrunt-babelというパッケージをインストールします。

$ npm install --global grunt-cli $ npm install --save-dev grunt grunt-babel

それでは変換してみましょう。

Gruntfile.jsに以下のように記述します。

module.exports = function(grunt) {
  grunt.initConfig({
    babel: {
      dist: {
        files: [{
          "expand": true,
          "cwd": "src/",
          "src": ["*.js", "**/*.js"],
          "dest": "dist/",
          "ext": ".js"
        }]
      }
    }
  });

  grunt.loadNpmTasks('grunt-babel');

  grunt.registerTask('default', ['babel']);
};

この状態でgruntコマンドを実行することで、src/以下のjsファイルをBabelで変換してdist/以下に書き出すことができます。

Browserifyを使った変換方法

ここまではタスクランナー経由での使い方を紹介しましたが、最後にBrowserify経由での変換方法もご紹介します。

Browserifyとは、以下のようにNode.jsで使える外部ライブラリを読み込むrequire構文（CommonJS）をブラウザ上でも使えるように変換するためのツールです。自動的に外部ライブラリの参照先のファイルを結合してひとつのファイルにまとめてくれます。

module.exports = function () {
  console.log('Hello browserify!');
};

var exportsCode = require('./exports.js');
exportsCode(); // console.log('Hello browserify!');

Babelは、同じように外部ライブラリを読み込むECMAScritpt2015 (ES6)のmodule構文を上記のようなrequire構文）に変換してくれますが、ひとつのファイルにまとめてくれる機能はありません。そのため、実際の実行ではエラーになってしまいます。

export default function () {
  console.log('Hello ES2015 exports!');
};

import exportsCode from './exports.js';
exportsCode(); // console.log('Hello ES2015 exports!');

これを解決するには、Babelだけでなく、Browserifyを組み合わせてrequire構文をブラウザでも実行できるようにする必要があります。これらを組み合わせた場合、ES2015のmodule構文で書いたものが、Babelによってrequire構文に変換され、require構文の（ブラウザでの）実行に必要なファイルの結合処理をBrowserifyが行う形となります。

このようにWebフロントエンドの開発の場合、BrowserifyとBabelはセットで使われることが多いです。

BrowserifyとBabelの連携方法は、単純にBabelの出力結果をBrowserifyに渡すだけでなく、Browserifyのもつプラグイン機構でBabelを呼び出すこともできます。

では、Browserify経由でBabelを実行するためのbabelifyというパッケージをインストールします。

$ npm install --global browserify $ npm install --save-dev babelify

Browserifyはgruntやgulp経由で起動する方法もありますが、以下のようにコマンドラインからでも起動できます。

$ browserify src/app.js -t babelify -o dist/app.js

-tでbabelifyを指定することで変換時にBabelを呼び出しています。

ここまで変換方法を紹介してきましたが、これ以外にも様々な方法でコードを変換することができます。

他のツールとの親和性はBabelの大きな特徴で、さまざまなツールを使用している状態でもスムーズに導入することができます。

オプション

ここまで紹介してきた内容でも最低限Babelでの変換は行えますが、細かい挙動を制御する場合オプションの指定が必要になる場合があります。

Babelにはさまざまなオプションがありますが、ここではその中から主要なものを取り上げて紹介します。

• stage

BabelはECMAScript2015 (ES6), ECMAScript7をECMAScript5に変換しますが、ECMAScript2015 (ES6), ECMAScript7の仕様でもまだ議論中のものもあり、安定度はまちまちです。

そこで、ECMAScriptの中でもまだ議論しきれていない仕様に関しては、stageという概念を使って安定度を示しています。

Babelはこのstageを指定する機能を備えており、stageを指定することでまだ議論の進んでいない仕様も使うことができます。

各stageでどういった機能が使えるようになるかは、こちらをご覧ください。

初期値は2が指定されており、草案（Draft）レベルのものが使用できます。

基本的には初期値で構いませんが、どうしても先取りしたい仕様がある場合には仕様が変わってしまうリスクを踏まえた上で、より新しい仕様を使うこともできます。

• sourceMaps

JavaScriptのコンパイラは性質上、元のソースコードと違った形式で出力されるため、実行時に何か問題があった場合にデバッグが困難になるという性質があります。

この問題に関しては標準仕様としてSourceMapという仕様が存在し、モダンブラウザではこの機能をサポートしています。

SourceMapを使うことで変換前のコードと変換後のコードを対応付けることができるため、実行時に問題が発生しても元のソース上でどこに問題があったのかを容易に把握することができます。

BabelのsourceMapsオプションはソースコードと同時にsourceMapファイルを出力することができ、trueを指定した場合変換後のソースとは別にsourceMapファイルを、”inline”を指定した場合変換後のソースファイルにsourceMapファイルを埋め込んで出力できます。

オプションの指定方法

さまざまなツールと連携できる点が魅力のBabelですが、連携する場合に問題になるのがBabel自体に対するオプションの指定方法です。

連携するツールによってはBabelに対してのオプションを指定する方法を提供している場合もありますが、場合によってはドキュメントに書かれていなかったり提供されていないこともあります。

そこで便利なのが設定を独立して記述できる.babelrcファイルです。

このファイルをBabelを実行するフォルダ（基本的にpackage.jsonと同じ場所）へ設置することで、連携ツール毎のオプション指定の方法を気にすることなく一括でオプションを指定することができます。

$ cat .babelrc { "stage": 1 }

最後に

駆け足でしたがここまでBabelの紹介をしてきました。

Babelを使った開発はすでに一般的に行われており、公開されている製品での使用もよく見るものになっています。

皆様もこれまでブラウザがサポートしなければ使えなかったECMAScriptの最新仕様を、自由に使える環境での開発を是非体験してみてください。

この記事は1/28に行われた、第44回HTML5とか勉強会（HTML5とセキュリティ編）で発表した内容を元に書いています。

今回はApplicationCacheのキャッシュポイズニングに関してお話したいと思います。

最初に用語について説明します。

ApplicationCache

ApplicationCacheとは、HTML5の「Offline Web Applications（日本語訳）」内で定義されているクライアントサイドキャッシュの仕様です。

キャッシュポイズニング

キャッシュポイズニングとは、キャッシュに対して攻撃コードを送り込み、そのキャッシュ経由で攻撃コードを実行させる攻撃手法です。

Googleで「キャッシュポイズニングを検索」した場合、検索結果の上位はDNSのキャッシュポイズニングに関する内容がほとんどですが、最近はクライアントサイドのキャッシュポイズニングも話題に上がるようになっています。

「クライアントサイドのキャッシュポイズニング」自体はApplicationCacheに限らず発生し得る問題ですが、ここでは特にApplicationCacheを使った場合のキャッシュポイズニングの問題に関して紹介したいと思います。

Man in the Middle Attack (MitM：中間者攻撃)

Man in the Middle Attack (MitM)とは攻撃者がターゲット（被害者）とサーバ（コンテンツ提供者）との通信を中継することで、不正な内容に置き換えたり、秘密の情報を盗み見る攻撃です。

具体的な攻撃方法は様々ですが、DHCPサーバの妨害、ルータの乗っ取り、無線APの詐称などで行われることがあります。

どういった問題か

まず、この問題の概要に関して紹介します。

簡単に言うと「安全でないネットワーク上でApplicationCacheを使用した場合に、攻撃データをApplicationCacheに追加させられると安全なネットワークに移動後も攻撃を受け続ける」という内容です。

これに関しては、OWASPという団体が公開している「HTML5 Security Cheat Sheet」や、JPCERT/CCが公開している「HTML5 を利用したWeb アプリケーションのセキュリティ問題に関する調査報告書」でも、それぞれ以下のように指摘されています。

攻撃シナリオ

概要のみだとどういった攻撃手法か理解しづらいため、具体的にどういった攻撃シナリオになるかを紹介します。

1. ターゲットの通信を乗っ取る（MitMを仕掛ける）
2. ターゲットがhttpでhtmlを要求したら、取得したhtml内に汚染したいURLをiframe[src]で記述して返す
   
3. iframe[src]で指定したURLをブラウザが取得しようとした場合、正規のhtml内に汚染したJSとApplicationCache自体のURLを記述したApplicationCacheを指定する

この攻撃のポイントとしては以下の2点です。

1. 中間者攻撃（MitM）が前提である
   ターゲットが取得しようとしたhtmlを書き換える必要が有るため、中間者攻撃（MitM）が前提となります。
2. ApplicationCache自体のURLをApplicationCacheに記述する
   ApplicationCacheは以下のようにApplicationCacheファイル（.appcache）にApplicationCacheファイル自体のURLを記述すると自動的にキャッシュが消えなくなります。
   アプリケーションキャッシュの使用 – HTML | MDN

CACHE MANIFEST /manifest.appcache

再度攻撃シナリオを見返す

ここで再度上で紹介した「攻撃シナリオ」を見てみたいと思いますが、まず最初にターゲットの通信を乗っ取っています。

つまり、この攻撃は「ターゲットの通信を乗っ取る（中間者攻撃（MitM）を行う）」事が前提になっており、この点でCSRFやXSSなどの攻撃手法とは性質が異なります。
（MitMができない場合、この攻撃は成立しない）

また、この攻撃はApplicationCacheを使うことでファイルが消えにくくなりますが、ApplicationCacheを使用しなかったとしても攻撃者がhttp headerを改変してキャッシュを有効にすることで攻撃コードを埋め込んだまま攻撃を継続することができます。

キャッシュポイズニングにおける本質的な課題

この記事ではここまで「各種セキュリティ団体が紹介するApplicationCacheのキャッシュポイズニングに関する注意喚起」の内容を紹介してきました。

しかし、著者はこの問題に関して「中間者攻撃（MitM）が必須である」という点で、他の攻撃手法とは性質が異なると考えます。

そもそもWebの世界では「コンテンツ提供者が中間者攻撃（MitM）に対処するにはhttpsしかない」という前提があります。
（MitMが成立した場合、攻撃者はコンテンツ提供者以上の権限を持つためコンテンツ提供者の対処を全て無効化できる）

そのため、「中間者攻撃（MitM）が必須である」場合、コンテンツ提供者がコーディングレベルで対応できることはありません。

また、「ApplicationCacheを使用しなくても同じような攻撃は可能である」点から、ApplicationCache自体の問題とすることにも疑問を感じます。

この問題は簡単に言うと「中間者攻撃（MitM）でキャッシュを汚染させられる」問題であり、ブラウザに外部の実行コード（html、JS等）をキャッシュする機構が備わっている以上避けられない問題だと考えます。

コンテンツ提供者がとるべき対応策は？

それではコンテンツ提供者はこの問題に対してどう対処すべきでしょうか。

基本的にコンテンツ提供者はコーディングレベルでこの攻撃方法に対処する方法はないと考えます。

何らかの対処コードを作成できたとしても、中間者攻撃（MitM）が成立している時点で、攻撃者は対処コードを除外した形でキャッシュを汚染することが可能です。

そもそもこの問題はApplicationCacheの問題ではなく、中間者攻撃（MitM）の問題のためサイト全体をhttpsにする以外、根本的な対応方法はありません。

結論

現時点での著者の結論をまとめます。

「ApplicationCacheのキャッシュポイズニング」に関して言うと、「コンテンツ提供者がApplicationCacheを使っている」ことで新しい脅威が増えるということはありません。
（攻撃者はコンテンツ提供者がApplicationCacheを使っているかどうかに関わらず、ApplicationCacheの機能を有効化して汚染できる）

中間者攻撃（MitM）に対しての対応は、これまでどおりサイトをhttps化することが有効になります。

利用者としては汚染が懸念されるネットワークの利用はできるだけ避けて、もし使用せざるを得ない場合ブラウザをシークレットモードで使用し、「サイトがhttpsで通信しているか」も確認した上で使用しましょう。

ここでは、「オフラインファースト」をはじめとする、モバイルなどの回線が不安定な状況を想定したWebアプリケーション設計に関して、キャッシュ方法やよく使われるAPIなどを紹介したいと思います。

「オフラインファースト」とは2012年ごろから提唱されていた、「回線がオフラインになることを前提にアプリケーションの設計を行う思想」のことで、オフライン前提に設計することにより回線状況によらないサービス提供や、効率的な通信をベースにした高速な動作を目指すものです。

それではここからはキャッシュ方法とそれぞれ向いているコンテンツの紹介を行います。

読み込みデータのキャッシュ

ApplicationCacheやlocalStorage、オンメモリキャッシュなどを使って、「サーバから取得したデータをローカルに保持する」ものです。

これは一般に「クライアントサイドキャッシュ」と呼ばれるもので、ネットワークがオンラインの時に読み込んだデータをオフライン時に使用します。

サーバと連動しないコンテンツに向いており、実際のコンテンツ以外でもテンプレートファイルなどの「動的なコンテンツの静的な部分」にも使用されます。

読み込みデータのマージ

これは「読み込みデータのキャッシュ」と大きくは変わりませんが、「読み込みデータのキャッシュ」がオンラインになった際に毎回キャッシュを読みなおすのに比べて、「読み込みデータのマージ」はオンラインになった際にサーバ上で更新があった内容のみダウンロードを行います。

更新があった内容のみダウンロードを行うため、帯域の使用量が少なくなる利点がありますが、サーバとクライアントでデータの更新タイミングを管理する必要があるため、「読み込みキャッシュ」に比べて実装が複雑になります。

「多数の画像ファイルの内、更新があったもののみを再取得する」など、やりとりするデータ量が多いコンテンツに使用されます。

書き込みデータのキャッシュ

書き込み時に回線状況を確認して、オフラインの場合オンラインになるまでデータの送信を遅延させる方法です。

また、オフラインだった時だけではなく、サーバへの通信に失敗した場合、常にデータを再送する形で実装されることもあります。

実装方法としては独自に定義した通信用のコードを使用するほかに、XMLHttpRequestを乗っ取る方法や、使用しているライブラリ（jQuery）などのajaxメソッドをラッピングする方法などがあります。

「投稿」や「保存」などのサーバへの更新処理に使われますが、ゲーム等のタイミングが重要な通信や、「購入」等のサーバ側との連動が、重要な通信では使用されません。

書き込みデータのマージ

これは「読み込みデータのマージ」に書き込みが行われることを想定されたものですが、「書き込みの時系列を保持するか」、「同じデータを同時に編集していた場合にどう整合性を保つか」等によって実装難易度は大きく変わります。
（時系列を保持せず、同時編集時は常に最後の修正が反映されれば良い場合、書き込みデータのキャッシュ実装と大きな差はありません）

これに関してはサーバ側の実装も大きく関わってくるためクライアント側だけで設計するのは難しいですが、もしクライアント側だけで実装したい場合にはGoogle Drive Realtime APIなどの外部サービスの使用も検討してみてください。

オフライン動作

これは単純なデータのキャッシュではなく「ブラウザがオフラインの状態でも動作させる」方法になります。

現状、ブラウザ上でオフライン時にコンテンツを提供するには、基本的にApplicationCacheを使用します。

サーバ側の処理が重要な場合オフライン動作の必要性は高くありませんが、クライアントサイドで完結する要素が多いモバイル向けのツールやアプリケーションなどでは必要性が高くなります。

ここからは実際にキャッシュを実装する際によく使用される機能について紹介します。

Web Storage（localStorage、sessionStorage）

IE8以降の主要なブラウザで使用できる同期型の保存領域です。

多くのブラウザは5MB程度のデータを保持することが可能です。

実装も容易なためよく使われますが、同期型で実装されているためパフォーマンス的な問題も指摘されています。

ローカルストレージに簡単な解決策はない | Mozilla Developer Street (modest)では具体的な問題点や代替案が書かれています。

Cookie

古くから実装されており、サポートブラウザも広いことから、長い間クライアントキャッシュの保存領域としても使用されてきました。

ただ、Cookieに保存した内容はサーバへも送信されてしまうことから、Cookieをキャッシュとして使用する場合、以後の通信すべてで不要なデータをサーバに送ることになるため、大きなデータをキャッシュすることには向いていません。

location.hash

URLの # 以降に文字列を設定し、クライアントキャッシュとして使用する方法です。

サーバサイドへも送信されず、古いブラウザでも動作可能ですが、「ブラウザの履歴に残る」、「URLを共有した際にキャッシュも共有される」、「ブックマーク等にキャッシュも保存される」、「#を使った画面遷移時にキャッシュが破棄される」といった問題があるため、キャッシュとして使用する場合は注意が必要です。

ブラウザキャッシュ

JavaScriptから直接操作するAPIは提供されていませんが、ブラウザキャッシュもクライアントサイドでは重要なキャッシュになります。

具体的には「非表示のimg要素を作成し、img.srcへ画像のURLを設定して先読みさせる」、「見えないiframeで次に読み込むページを先読みする」といった方法で使用されます。

Web SQL Database

ブラウザ内に内蔵されたSQLiteに対して、JavaScriptからAPI経由でSQLを発行することでデータの保存、取得を行うのがWeb SQL Database APIです。

もともとWebKit系のブラウザで実装されており、W3Cでも標準仕様として提案されていましたが、SQLiteへの依存などの問題によりW3C上では廃案になりました。
（ブラウザ上のデータベースに関して – JavaScriptで遊ぶよ – g:javascriptでは廃案になった経緯等がまとめられています）

ただ、モバイル環境では使える環境が多いため、モバイル環境に限ったウェブアプリケーションなどでは使用されることもあります。

Indexed Database（Indexed DB）

標準仕様としての策定が中止されたWeb SQL Databaseに代わり登場したクライアントサイドDBです。

Web SQL DatabaseがあくまでもSQLiteの仕様に準拠しているのに比べて、Indexed DatabaseはJavaScriptからの使用に特化しておりシンプルなObjectやFile objectなどをそのまま格納できます。

Chrome、Firefox、IE10でサポートされるなど、デスクトップブラウザではサポートが広まっていますが、Mobile Safari、Android標準ブラウザでのサポートが行われていないためモバイル環境での使用は広まっていません。

Filesystem API

ブラウザ上にディレクトリなどのFilesystemを操作するAPIを提供するのが、Filesystem APIです。

DOMFileSystem objectやDirectoryEntry objectなどを使って、File objectを階層構造で管理することができます。

このAPIはinput[type=”file”]やD&Dで渡されたファイルを処理する際に使用する「File API」とは違うAPIであることに注意してください。
（Filesystem APIでも単一のファイルを操作する際はFile APIで提供される機能を使用しますが、File APIはあくまでもFilesystem APIから独立した仕様です）

主にChromeで実装されていますが、Chrome以外のブラウザでは実装が進んでいないため、一般的なウェブ環境ではあまり使用されていません。

Firefox に FileSystem API が無いのはなぜか？ | Mozilla Developer Street (modest)ではMozillaのFileSystem APIに対するスタンスが書かれています。

ApplicationCache

ApplicationCacheはcache manifestと呼ばれるキャッシュ対象のURLを記述したテキストファイルをhtmlから参照することで、記述されているURLの内容をローカルキャッシュとして使用する仕様です。

ApplicationCacheには以下の様な機能が含まれます。

• ブラウザがオフラインでも、事前にキャッシュした内容を表示する
• ネットワーク通信なしに、cache manifestに書かれたURLのファイルにアクセスする
• ブラウザがオフライン時のみ、代替内容を表示する
• JavaScriptからキャッシュの取得、更新イベントを受け取る

現在、ブラウザがオフライン時でもコンテンツを提供する場合ApplicationCacheが主に使用されますが、ApplicationCacheは「設計に失敗したAPI」と呼ばれるほど使い勝手が悪く、さまざまな問題を抱えています。

ApplicationCacheの問題点

ApplicationCacheに関しての紹介で「さまざまな問題を抱えています」と書きましたが、ここではそのうちの主なものについていくつか紹介したいと思います。

読み込み元htmlがキャッシュされる

ApplicationCacheを使用する場合、仕様上ApplicationCacheを使用しているhtmlもキャッシュされてしまうため、動的なコンテンツを出力してもすぐに反映されません。

そのため、ApplicationCacheを使用する場合は基本的に1枚の静的なhtmlを用意し、動的な部分はすべてJavaScriptを使用して構築することになります。

これはWebサイト構築の当初から想定している場合は問題ありませんが、サーバサイドで動的にコンテンツを生成している既存のWebサイトに対して、あとからApplicationCacheを導入する場合には大きな障害になります。

キャッシュのクリアが困難

ブラウザによってはApplicationCacheをクリアするUIを提供していないものもあり、開発中も含めて一度キャッシュされたApplicationCacheをクリアするのが困難な場合があります。

特にiOSの場合、アプリが独自に使用しているUIWebViewのApplicationCacheをクリアするには、アプリを削除して入れなおす以外の方法がありません。
（アプリが独自のUIを提供している場合を除く）

JavaScriptからキャッシュを操作することができない

JavaScriptからApplicationCacheに関しては「キャッシュ状態の確認」、「サーバ上のデータ確認」、「キャッシュの破棄」を行うことができます。

ただし、キャッシュ操作は全キャッシュに対しての操作のみで、個別のファイルに対しての操作は提供されていません。

そのため、「高速化のために出来るだけキャッシュするファイルを多くしたいが、キャッシュするファイルが多いとキャッシュの更新に時間がかかる」という状況になります。

キャッシュの更新は自動的に行われるため基本的にブラウザ側で操作を行う必要はありませんが、逆に「一部のキャッシュのみ更新したい」、「更新順に優先度を付けたい」、「指定したキャッシュが更新されたらJavaScriptからアクセスしたい」と言った内容は実現できません。

それでも使われるApplicationCache

問題点の多いApplicationCacheですが、現状ブラウザがオフライン時にコンテンツを提供するためにはもっとも現実的な方法であるため、問題点があることを前提で使用されている状況です。

もしApplicationCacheを導入する場合、以下の点に注意してください。

最初に導入するか決断する

ApplicationCacheは仕様的にシングルページアプリケーション（1枚のhtmlをベースにJavaScriptでコンテンツを構築する形式）を想定しており、サーバサイドで毎回htmlを組み立てて出力する形式は想定されていません。

サーバサイドで毎回htmlを組み立てて出力するコンテンツの場合でもiframeを経由するなどして活用することは可能です。しかし、iframe内のApplicationCacheに対する状態管理とiframeと、本体間のキャッシュデータをやりとりするコードが必要になるため、実装は複雑になります。

最悪の事態を想定する

ApplicationCacheは使い方によっては完全にサーバから独立して動く事が可能ですが、場合によってはサーバからの変更を一切受け付けなくなってしまう状態に陥る場合があります。

もしサイト上でApplicationCacheを使用する場合、常にネットワーク上からダウンロードするJavaScriptを読み込ませておき、最悪の場合でもJavaScriptからリダイレクトの指示を出せるようにしておくことをおすすめします。

ここまでキャッシュの設計やAPIに関して紹介してきましたが、ユーザから見た場合キャッシュとは「最良の通信やパフォーマンスが提供されない場合の代替手段」であり、本来存在しないことが求められる技術でもあります。

そのため、もしキャッシュを使用する場合、「ユーザの意図に反した動作にならないか」、「最良の状態でないことをユーザが理解できるか」といったことを意識して使用してください。