プラグインの光と影

　プラグインは、Webブラウザの機能が現在より限られていたWebの初期に登場した。プラグインにより、アプリケーションのローカルインストールをエンドユーザーに要求することなく、高度な機能をWebブラウザで実行することが可能になった。

　こうしたプラグインの中心的な存在だったのが「NPAPI」（Netscape Plugin API）だ。NPAPIは全てのWebブラウザで使用可能な標準を提供した。これによってクロスブラウザ／クロスプラットフォーム機能が実用化された。FlashやSilverlight、Javaといった技術はNPAPIを利用して、クライアントソフトウェア的な機能をWebアプリケーションで実現した。そのおかげでWebブラウザは、高度なアプリケーションのプラットフォームに進化した。

　ところが、こうしてNPAPIの恩恵が広がって間もなく、エンドユーザーからフルパーミッションを与えられたプラグインにより、他のサイバー世界と隔離されずにコードが実行されることの弊害が表面化した。Webブラウザやプラグインのベンダーはセキュリティホールに突然直面し、際限なく続く攻撃に対処しなければならなくなった。こうした攻撃はシステムへのマルウェア感染や、情報の流出、データセンターの停止につながる恐れがある。

　プラグイン技術のセキュリティリスクは甚大だ。JavaとFlashは、いずれもサイバー犯罪者の格好の標的になっている。しかも、プラグインはセキュリティ以外にも、システムのハング、クラッシュ、復元不能な損傷といったさまざまな問題を引き起こしている。

開発者は何をすべきか

　開発者は既に、Webブラウザプラグインを使わずに済ませる方法を探っている。古い技術を排除し、新しい技術を取り入れてソフトウェアの書き換えを進めているところだ。HTML5の台頭は、JavaScriptやCSSの進化とともに、今日のWebベースアプリケーションの変革を後押ししている。

　JavaアプレットAPIは、当面は非推奨になるだけであり、削除されるわけではない。そのため開発者は、まだJavaアプレットAPIを継続利用することもできるが、限られたサポートしか受けられない。さらにコードのコンパイル時に“Java非推奨エラー”に見舞われることになる。Javaコンパイラが警告をエラーとして扱うように構成されていれば、ビルドが失敗してしまうのだ。

　大企業では、多くの分散アプリケーションを利用している場合、JavaアプレットAPIがどこに実装されているか分からないという問題もある。だが幸い、開発チームはJava統合管理ツール「Java Advanced Management Console」を使って、Javaの使用状況を追跡し、JavaアプレットAPIがどこで使われているかを判断できる。

　JavaアプレットAPIを使わないようにコードを変更する際には、開発者はHTML5などの先進的なWeb技術を利用することや、Oracleから提供されている選択肢のいずれかを選ぶことができる。例えばOracleは、開発者がJavaアプレットAPIの代わりに「Java Web Start」を使用できると述べている。Java Web Startは、エンドユーザーがプラグインなしで、Javaアプリケーションをインターネットから起動できる仕組みだ。だが「ブラウザプラグインの場合と同様に、ハッカーがJava Web Startを使って、Javaの脆弱（ぜいじゃく）性を悪用できてしまうのではないか」と懸念する声もある。

　いずれにしても開発チームは、プラグインを使わない選択肢を追求する必要がある。Javaプラグインは将来的な廃止が既定路線となっており、FlashやSilverlightも同様だ。Microsoft Edgeでさえ、Microsoft自身の技術であるSilverlightをサポートしていない。プラグインに依存したアプリケーションは書き換える必要があり、新しいアプリケーションでは、これらの技術は完全に排除しなければならない。