公開日
WebAssemblyの現状は？ 大規模調査が明かす利用実態・セキュリティリスク
WebAssembly（Wasm）は、ウェブブラウザ上で高速なコード実行を可能にする技術として、2017年の登場以来、大きな注目を集めてきました。JavaScriptの性能的な限界を補い、C/C++やRustといった多様な言語で書かれたコードをネイティブに近い速度で動かせることから、特に計算負荷の高いウェブアプリケーションのパフォーマンス向上策として期待されています。しかし、「Wasmは本当に普及しているのか？」「セキュリティは大丈夫？」といった疑問の声も少なくありません。
この記事では、そんな疑問に答えるため、The Hong Kong Polytechnic Universityなどの研究チームが行った大規模調査「The Promise and Pitfalls of WebAssembly: Perspectives from the Industry」（2025年）の結果を詳しく解説します。この調査は、実際にウェブ上で利用されている4,600以上のユニークなWasmバイナリを分析対象としており、その利用実態、技術的な特徴、セキュリティ上の課題、そして具体的な使われ方について、データに基づいた客観的な視点を提供します。
WebAssemblyはどの程度使われているか？普及状況と利用環境
まず、Wasmがウェブの世界で実際にどの程度、どのように利用されているのかを見ていきましょう。
Wasmの採用状況：普及レベルと今後の可能性
調査によれば、Wasmは2017年の登場後、徐々に本番環境で採用され始め、特に2021年以降、利用するウェブサイトが増加傾向にあります。2023年には一時的な急増も見られましたが、後述するように特定のフィッシング詐欺キャンペーンの影響も含まれている点には注意が必要です。
ただし、ウェブ全体で見ると、Wasmの普及はまだ限定的と言わざるを得ません。有名なウェブサイトランキング「Cisco Umbrella Top 1 Million」に含まれるサイトのうち、Wasmを利用（過去の利用を含む）していたのは全体の17.0% に留まります。影響力の大きいTop 100サイトではわずか7サイト、Top 1,000サイトでも171サイトと、主要サイトでの採用はまだ少数派です。この結果は、Wasmがフロントエンド開発における標準技術とまではなっていない現状を示唆しています。
利用サイトの地理的分布：米国が突出、地域差も
Wasmを利用しているウェブサイトは、どの国や地域に多いのでしょうか？ホスティングされているIPアドレスに基づくと、米国が突出して多く、全体の59% を占めています。次いでドイツ（14%）、オランダ（6%）、フランス（3%）、スイス（2%）といったヨーロッパ諸国が続きます。興味深いのは、開発者人口が多いとされる中国やインドといった国々からの利用が比較的少ない点です。Wasm技術の普及や採用には、地域的な偏りがある可能性がうかがえます。
Wasmをホストするウェブサイトの国別分布(一部抜粋)
| 国/地域 | 割合 (%) |
|---|---|
| 米国 | 59 |
| ドイツ | 14 |
| オランダ | 6 |
| フランス | 3 |
| スイス | 2 |
| 英国 | 1 |
| 韓国 | 1 |
| 日本 | 1 |
注意喚起：フィッシングサイトにおけるWasm利用
調査の中で特に注目すべきは、Wasmをホストしているサイトの中に、悪意のあるものが含まれているという点です。調査対象となったWasm利用サイト（約7万8千）のうち、外部サービス（urlscan.io）によって約17.1%にあたる約1万3千サイトが「悪意あり（malicious）」と判定されました。さらに驚くべきことに、この「悪意あり」と判定されたサイト群の中で、実に99%以上がフィッシング詐欺サイトに分類されたのです。 これは、Wasmを利用しているサイト全体が悪意を持っているわけではありませんが、悪意を持ってWasmを利用するケースにおいては、フィッシング詐欺が非常に多いことを示唆しています。
偽装対象として最も多かったのはFacebook（69.1%）で、次いでコロンビアの銀行Bancolombia（27.9%）、ペルーの銀行Interbankpe（2.0%）などが続きます。Wasm自体が悪意を持つわけではありませんが、コードの解析を難しくするなどの技術的特性が悪用されている可能性も考えられます。開発者やセキュリティ担当者は、Wasmを取り巻くこのようなリスクにも目を向ける必要があります。
Wasmバイナリの技術的側面：サイズ、言語、ツールチェーンの分析
次に、実際に使われているWasmバイナリが、技術的にどのような特徴を持っているのかを見ていきましょう。ファイルサイズ、開発言語、コンパイルツールチェーンについて分析します。
ファイルサイズの実態：「軽量」というイメージは本当か？
Wasmのメリットとして、バイナリ形式であることによる「コンパクトさ」が挙げられることがあります。しかし、調査結果は、実環境のWasmバイナリが必ずしも軽量ではないことを示しています。
分析対象となった4,600以上のユニークなWasmバイナリのファイルサイズ分布を見ると、一般的なJavaScriptの平均サイズ（約27.3KB、HTTP Archive調べ）と比較して、大きいものが多い傾向にあります。実際に、ファイルサイズが30KB未満のWasmバイナリは、ユニークなものでは全体の17.7%に過ぎません。 重複を考慮した場合でも、30KB未満は約21.4%でした。もちろん非常に小さなバイナリもありますが、多くの場合、Wasmは期待されるほどのサイズ効率を発揮できていない可能性があります。これは、バイナリ内に含まれるランタイム機能、ライブラリ、あるいはデバッグ情報などが影響していると考えられます。
ユニークな実環境Wasmバイナリのファイルサイズ分布（KB）
注：図は比較のため1MB以下のファイルサイズに限定して表示されています。
Wasm開発に使われるプログラミング言語：C/C++とRustが主流
Wasmは多様な言語からコンパイル可能ですが、実際にはどの言語が多く使われているのでしょうか？調査では、バイナリ内の特徴的な文字列などからソース言語を推測する手法を用いています。
その結果、最も多く利用されているのはC/C++で、全バイナリ（重複考慮）の53.8% を占めています。これは、既存のC/C++コード資産の活用や、パフォーマンス重視のライブラリ開発などでWasmが選ばれていることを示唆します。次いで多いのがRust（17.8%）、そしてC#（ASP.NET経由、6.7%） です。Go言語からのコンパイルも存在しますが、割合は3.0%と比較的少数派でした。ソース言語を特定できなかった「不明」（18.7%）は、コードの難読化などが影響していると考えられます。現状、Wasmエコシステムは特定の言語にやや偏った利用状況にあると言えそうです。
検出されたWasmバイナリのソース言語別割合（重複考慮）
| ソース言語 | 割合 (%) |
|---|---|
| C/C++ | 53.8 |
| 不明 | 18.7 |
| Rust | 17.8 |
| C# | 6.7 |
| Go | 3.0 |
| 合計 | 100.0 |
主要なコンパイルツールチェーン：EmscriptenとClangが中心
ソース言語と同様に、Wasm開発でよく使われているコンパイルツールチェーン（コンパイラや関連ツール）も見てみましょう。
最も広く使われているのは、C/C++からWasmへのコンパイルツールとしてデファクトスタンダードとなっているEmscripten（28%） と、LLVMベースのコンパイラであるClang（26%） です。これら二つで半数以上を占め、Wasmエコシステムの中心的な役割を担っています。Rust言語からはRustc（18%） が用いられ、C#の利用率に対応するようにASP.NETツールチェーン（7%） も一定のシェアを持っています。Go言語では、公式コンパイラがTinyGoよりも多く利用されています。ツールチェーンによって生成されるWasmバイナリの特性（サイズ、実行環境との互換性など）は異なるため、開発者は目的に応じた選択が求められます。
検出されたWasmバイナリのコンパイルツールチェーン別割合（重複考慮）
| コンパイルツールチェーン | 割合 (%) |
|---|---|
| Emscripten | 28.10 |
| Clang | 25.85 |
| 不明 (unknown) | 18.75 |
| Rustc | 17.57 |
| ASP.NET | 6.75 |
| Official Go | 2.98 |
使用されたコンパイルツールチェーンごとのファイルサイズ分布(重複考慮)
WebAssemblyのセキュリティ課題：マルウェアと脆弱性
Wasmの性能と移植性は魅力的ですが、セキュリティ面での課題も見過ごせません。調査で明らかになったWasmマルウェアの実態と、Wasmバイナリに潜む可能性のある脆弱性について解説します。
Wasmを用いたマルウェア：クリプトマイナーの検出事例
調査対象のWasmバイナリをウイルス対策サービス（VirusTotal）でスキャンした結果、8つのバイナリがマルウェア（具体的にはクリプトマイナー）として検出されました。 これらは、ウェブサイト訪問者のPCリソースを無断で利用し、暗号通貨を採掘（マイニング）するタイプのマルウェアです。
検出されたマルウェアの多くには、「cryptonight」という特定のマイニングアルゴリズムに関連するキーワードが含まれていました。興味深いことに、これらの多くは2017年末から2018年半ばに展開され、その後更新されていない傾向が見られました。これは、当時活動していた特定のクリプトマイニングサービス（Coinhiveなど）の影響と考えられます。また、cpuminer_native.wasm や google.wasm のように、ファイル名を偽装して検出を逃れようとする手口も確認されています。検出数は少ないものの、Wasmが悪意のある目的に利用されうることを示す重要な証拠です。
Wasmバイナリに潜む脆弱性：3つの注目ポイント
Wasmバイナリ自体に、悪用可能な脆弱性が潜んでいる可能性も指摘されています。調査では、特に以下の3点に注目して分析を行いました。
1. メモリ保護が効かないスタック領域（非管理コールスタック）
多くのWasmバイナリ（調査対象の約60%）は、C/C++などからコンパイルされる際、プログラム自身のコールスタック（関数の呼び出し履歴やローカル変数を格納する領域）をWasmの線形メモリ内に確保します。この領域はOSによる標準的なメモリ保護（ASLRやスタックカナリアなど）の対象外となるため、「非管理コールスタック」と呼ばれます。
攻撃者がこの非管理コールスタックへの書き込み権限を何らかの方法で得た場合、バッファオーバーフロー攻撃などによりリターンアドレスを書き換え、意図しないコードを実行させる危険性があります。調査では、対象バイナリの約36%の関数がこの非管理コールスタックにアクセスしており、中には1KBを超える大きなスタックフレームを持つ関数も存在しました。これは攻撃者にとって格好の標的となりえます。
2. プログラムに埋め込まれるメモリ管理機能（静的リンクされたアロケータ）
Wasmの標準機能だけでは柔軟なメモリ管理（動的な確保・解放）が難しいため、多くのコンパイラはmallocやfreeといったメモリ管理ライブラリ（メモリアロケータ）をWasmバイナリ内に直接埋め込みます（静的リンク）。
調査では、dlmalloc（Emscriptenで多用）やGo言語の標準アロケータ、軽量なwee_allocなどが検出されました。これらのアロケータ、特に軽量化やカスタマイズされたものの中には、既知の脆弱性を持つものや、実装上の不備によりメモリ破壊を引き起こす可能性があるものが存在します。攻撃者はこれらの脆弱性を悪用し、プログラムの制御を奪取しようとするかもしれません。
3. 外部機能呼び出し（セキュリティ関連APIのインポート）に伴うリスク
Wasmバイナリは、外部環境（ブラウザやNode.jsなど）が提供する機能（API）を呼び出して動作することが一般的です。これらのAPIの中には、ファイルシステムアクセス、ネットワーク通信、外部コマンド実行、DOM操作など、セキュリティ上慎重な扱いが必要なものが含まれます。
調査では、デバッグ情報が含まれるWasmバイナリを対象に、呼び出しているAPI名を分析しました。その結果、ファイル関連（fd_*, path_*など）が804件と最も多く、次いで外部コマンド実行関連（exec, evalなど）が248件検出されました。ネットワーク関連（sock_*）やDOM関連（documentなど）、動的リンク関連（dlopen）も少数ながら確認されました。これらのAPIが悪用されると、情報漏洩、不正コマンド実行、クロスサイトスクリプティング（XSS）といったインシデントにつながる恐れがあります。デバッグ情報がない場合、これらのAPI利用の検出はさらに難しくなります。
Wasmバイナリでインポートされているセキュリティ関連APIの分類別件数
| APIカテゴリ | ユニークWasmバイナリ数 | 割合 (4,606件中) | Wasmバイナリ数 (重複考慮) | 割合 (20,433件中) |
|---|---|---|---|---|
| ファイル | 804 | 17.5% | 2,687 | 13.2% |
| ネットワーク | 23 | 0.5% | 55 | 0.3% |
| 実行 | 248 | 5.4% | 1,050 | 5.1% |
| DOM | 8 | 0.2% | 17 | 0.1% |
| 動的リンク | 3 | 0.1% | 9 | <0.1% |
| 合計 | 1,086 | 23.6% | 3,430 | 16.8% |
WebAssemblyの主な用途：何のために使われているのか？
Wasmは、実世界でどのような目的のために利用されているのでしょうか？代表的なWasmバイナリの分析から見えてきた主要な用途を解説します。
計算負荷の高い処理：グラフィックとフォントが中心
調査では、利用頻度の高い上位100のWasmバイナリについて、専門家が手動でその機能を分析し、用途を分類しました。その結果、最も多かった用途はグラフ処理（34%） でした。具体的には、ビデオストリームのデコードやベクターグラフィックスのレンダリングなどが含まれます。これは、Wasmが当初から目指した「計算負荷の高いタスクをウェブブラウザ上で高速に実行する」という目的に合致する結果です。
次に多かったのはフォント処理（19%） です。ウェブページ上で複雑なフォントを効率的に描画するためにも、Wasmの計算能力が役立っています。これも広義のグラフィックス処理と捉えられます。
最も代表的なWasmバイナリ上位100種の用途分類
| カテゴリ | 件数 |
|---|---|
| グラフ処理 | 34 |
| フォント処理 | 19 |
| 仮想環境 | 18 |
| ユーティリティ | 13 |
| 暗号化 | 11 |
| 不明 | 5 |
仮想環境、ユーティリティ、暗号化など多様な応用
グラフィックやフォント以外にも、Wasmは多様な用途で使われています。仮想環境（18件） カテゴリには、特定のハードウェア（ゲーム機など）やソフトウェアをブラウザ上でエミュレートする仮想環境や、他のプログラミング言語のランタイムを提供するものが含まれます。これはWasmの高い移植性を活かした応用例です。
また、ユーティリティ（13件） として、文字列照合や正規表現といった比較的小規模ながら便利な機能や、暗号化（11件） に関連するライブラリ（擬似乱数生成器など）も確認されました。これらの機能はJavaScriptでも実現可能ですが、パフォーマンスや既存ライブラリの活用といった観点からWasmが選択されていると考えられます。
結論：Wasmエコシステムの現状評価と未来への提言
今回の大規模調査は、実環境で利用されるWebAssembly (Wasm) のリアルな姿を浮き彫りにしました。Wasmは、計算負荷の高い処理における性能、そして多様な言語からのコンパイル可能性という強みを持ち、グラフ処理、フォント処理、仮想環境などで実際に活用され始めています。一方で、その普及はまだ限定的で、ファイルサイズも必ずしも軽量とは言えません。開発言語やツールチェーンには偏りがあり、セキュリティ面ではマルウェアへの悪用や潜在的な脆弱性といった課題も存在します。特にフィッシングサイトでの利用頻度の高さは懸念材料です。Wasmは大きなポテンシャルを秘めつつも、エコシステム全体としてはまだ発展途上にあると言えるでしょう。
WebAssemblyは、ウェブの可能性を大きく広げる技術です。その「光」の部分を最大限に活かしつつ、「影」の部分に適切に対処していくことで、より豊かで安全なウェブの未来を築くことができるでしょう。
Webサービスや社内のセキュリティにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料: