Base64とは？仕組み・変換例・URL-safe Base64との違い・セキュリティリスクを徹底解説｜サイバーセキュリティ.com

  1. ホーム /
  2. コラム /
  3. Base64とは？仕組み・変換例・URL-safe Base64との違い・セキュリティリスクを徹底解説
             

Base64とは？仕組み・変換例・URL-safe Base64との違い・セキュリティリスクを徹底解説



「Base64って何？」「これって暗号化なの？」「セキュリティ的に大丈夫なの？」——エンジニアでもセキュリティ担当者でも、Base64を正しく理解していない方は意外に多いです。

Base64とは、バイナリデータ（画像・ファイルなど）を64種類のASCII文字だけで表現できるテキストに変換するエンコーディング方式です。メール添付ファイル・HTTP通信・Web開発・認証情報の転送など、インターネットの至る所で使われています。

本記事では、Base64の仕組み・具体的な変換例・URL-safe Base64との違い・用途・セキュリティリスク・FAQまで徹底解説します。

 Base64は暗号化ではありません
Base64は「形を変えるだけ」で、「誰が読めるか」は一切変えません。エンコードされた文字列は誰でも1行のコードで元に戻せます。データが機密であれば暗号化（AES・RSAなど）を使ってください。

Base64とは？

Base64とは、バイナリデータを64種類のASCII文字だけを使ったテキストに変換するエンコーディング方式です。英語の「base」は「基数」を意味し、「Base64」は64を基数とした表現方法という意味です。

「ファイルを引越し用の段ボール箱に詰める」たとえ
バイナリデータ（画像・ファイル）はそのままでは一部のシステムで壊れてしまいます（引越しで壊れやすい荷物）。Base64はその荷物を安全に運べる標準的な段ボール箱（テキスト形式）に詰め替える作業です。目的地（受信側）で箱を開けて（デコード）元の荷物（バイナリ）を取り出します。

Base64で使われる64種類の文字

値 文字 説明
0〜25 A〜Z 大文字アルファベット26文字
26〜51 a〜z 小文字アルファベット26文字
52〜61 0〜9 数字10文字
62 + 記号（URL-safeでは「-」）
63 / 記号（URL-safeでは「_」）
パディング = 値ではなくブロック調整用の文字

Base64の仕組み（変換の手順）

Base64エンコードは「3バイトのバイナリを4文字のテキストに変換する」の繰り返しです。

基本のルール

  • 3バイト（24ビット）→ 4文字：エンコード後は常に約33%データ量が増える
  • 6ビット単位で分割：8ビット×3バイト＝24ビットを、6ビット×4グループに切り直す
  • パディング「=」：入力が3バイトの倍数でない場合、末尾に「=」または「==」が追加される

具体例：「Hello」をBase64にエンコードする

ステップ①：各文字をASCIIコード→2進数に変換

文字 ASCIIコード 2進数（8ビット）
H 72 01001000
e 101 01100101
l 108 01101100
l 108 01101100
o 111 01101111

ステップ②：3バイトずつまとめて6ビット4グループに分割

「Hel」の24ビット「010010000110010101101100」を6ビットずつに分けると：

010010 → 18 → S
000110 → 6 → G
010101 → 21 → V
101100 → 44 → s

ステップ③：最終結果

「Hello」は5バイト（3の倍数でない）なので末尾に「=」が1つ付きます。

「Hello」 → Base64エンコード → SGVsbG8=
「=」の数でわかること
末尾の「=」はパディング（穴埋め）を示します。「=」なし → 入力が3バイトの倍数、「=」1つ → 余り2バイト、「==」2つ → 余り1バイト

標準Base64とURL-safe Base64（Base64URL）の違い

標準Base64には「+」「/」「=」が含まれますが、これらはURLやファイル名の中で問題を引き起こすことがあります。

問題の文字 URLでの問題 URL-safeでの代替文字
+ クエリ文字列で「空白」として解釈される – （ハイフン）
/ パスの区切り文字として解釈される _ （アンダースコア）
= キーと値の区切り文字として解釈される 省略（パディングなし）

URL-safe Base64（Base64URL、RFC 4648 §5）はJWT・OAuth・APIなどのWeb認証に広く使われています。

Base64の主な用途

メール添付ファイルのエンコード（MIME）

初期のメールシステムはテキストのみを扱えたため、画像やPDFなどのバイナリファイルをBase64でテキストに変換してから送信します。MIME（Multipurpose Internet Mail Extensions）の仕様でBase64が標準採用されています。

HTTP通信・API認証（Basic認証）

HTTP Basic認証では、「ユーザー名:パスワード」という文字列をBase64でエンコードしてHTTPヘッダーに付加して送信します。

例：ユーザー名「admin」・パスワード「password」の場合
→「admin:password」をBase64エンコード → 「YWRtaW46cGFzc3dvcmQ=」
→ HTTPヘッダー：Authorization: Basic YWRtaW46cGFzc3dvcmQ=⚠️ Base64は暗号化でないためHTTPSと組み合わせて使わないと平文と同等です

Webページへの画像・データの埋め込み（Data URI）

HTMLやCSSに画像をBase64で直接埋め込むことで外部ファイルへのリクエストを削減できます。

<img src=”data:image/png;base64,iVBORw0KGgoAAAANS…” alt=”画像”>

小さなアイコンや背景画像に有効ですが、大きな画像ではデータ量が33%増えるためかえって遅くなることがあります。

JWT（JSON Web Token）のデータ格納

JWT（認証トークン）のヘッダーとペイロード部分はBase64URLでエンコードされています。JWTは署名によって改ざんを検知できますが、ペイロード部分はBase64URLをデコードするだけで誰でも読めます。機密情報をJWTペイロードに含める際は別途暗号化が必要です。

証明書・鍵ファイル（PEMフォーマット）

SSL/TLS証明書や秘密鍵のPEMフォーマットはBase64でエンコードされたバイナリデータをテキストとして格納しています。「—–BEGIN CERTIFICATE—–」で始まるファイルがBase64エンコードの証明書です。

Base64のデコード・エンコードのコード例

Python

import base64

# エンコード
text = “Hello”
encoded = base64.b64encode(text.encode(“utf-8”))
print(encoded) # b’SGVsbG8=’

# デコード
decoded = base64.b64decode(“SGVsbG8=”)
print(decoded.decode(“utf-8”)) # Hello

JavaScript（Node.js）

// エンコード
const encoded = Buffer.from(“Hello”).toString(“base64”);
console.log(encoded); // SGVsbG8=// デコード
const decoded = Buffer.from(“SGVsbG8=”, “base64”).toString(“utf-8”);
console.log(decoded); // Hello

コマンドライン（Linux・Mac）

# エンコード
echo -n “Hello” | base64
# 出力: SGVsbG8=# デコード
echo “SGVsbG8=” | base64 –decode
# 出力: Hello

Base64のメリットとデメリット

メリット

  • 互換性の向上：バイナリデータをどのシステムでも処理可能なテキストに変換できる
  • シンプルな実装：ほぼすべてのプログラミング言語に標準ライブラリが用意されている
  • 転送中のデータ破損防止：テキスト専用の経路でも安全にバイナリを通過させられる

デメリット・注意点

  • データサイズが約33%増加：3バイトが4文字になるため大量データ処理では通信コストに影響する
  • 暗号化ではない：誰でも1行でデコードできるためセキュリティ保護にはならない
  • 可読性の低下：ログやデバッグ時にエンコードされた文字列は人が読めず調査が難しくなる
  • マルウェアの隠蔽に悪用される：悪意あるコードをBase64でエンコードしてセキュリティツールの検知を回避する攻撃が多発している

Base64のセキュリティリスク：悪用の手口

Base64は正当な技術ですが、サイバー攻撃者に悪用されるケースが急増しています。

マルウェアの難読化（HTMLスマグリング）

攻撃者は悪意あるコード（マルウェア・実行ファイル）をBase64でエンコードしてHTMLファイルや画像タグ内に埋め込みます。ブラウザがHTMLを読み込む際にBase64を自動デコードして実行するため、セキュリティソフトの検知を回避できます。

シグネチャ検知の回避

従来のウイルス対策ソフトは既知のマルウェアの「パターン（シグネチャ）」で検知しますが、Base64エンコードによってパターンが変化するため検知が困難になります。Base64エンコードしたマルウェアは同じウイルスでも全く別の文字列になります。

フィッシングメールでの活用

フィッシングメール内にBase64エンコードされたリンクや悪意あるスクリプトを隠すことで、メールセキュリティフィルターの検知を回避する手法が使われています。

 Base64文字列を見かけたら注意するポイント

  • 不明なソースから届いたBase64文字列を安易に実行・デコードしない
  • メール内の長いBase64文字列は悪意あるペイロードが含まれる可能性がある
  • Base64デコードで実行ファイルが生成された場合は絶対に実行しない

Base64に関連する悪用・注意事例2選

事例1：HTMLスマグリングによるQakBot配布

QakBot（Qbot）は、メール攻撃などで拡散されるマルウェアで、認証情報の窃取や他のマルウェアの侵入経路として悪用されることがあります。Trend Microの調査では、QakBotの攻撃メールでHTMLスマグリングが使われ、メールスレッドの乗っ取りと組み合わせて、メールセキュリティをすり抜けようとする手口が確認されています。

HTMLスマグリングでは、HTMLやJavaScriptの正規機能を悪用し、Base64などでエンコードされた悪意あるファイルをブラウザ上で復元させることがあります。Base64は正当なエンコーディング方式ですが、攻撃者にとってはマルウェア本体やスクリプトを隠すための手段にもなります。不審なHTML添付ファイルや、長いBase64文字列を含むメールは開かないことが重要です。

参考：QAKBOT Sneaks in Via HTML Smuggling and HTML Downloader｜Trend Micro

事例2：Basic認証の認証情報がBase64で送信される注意点

HTTP Basic認証では、ユーザー名とパスワードを「ユーザー名:パスワード」の形式にしてBase64エンコードし、Authorizationヘッダーに含めて送信します。RFC 7617でも、Basic認証はユーザーIDとパスワードのペアをBase64でエンコードして送信する方式として定義されています。

Base64は暗号化ではなく、誰でも簡単に元の文字列へ戻せるため、HTTPのような暗号化されていない通信でBasic認証を使うと、認証情報が盗聴されるリスクがあります。Basic認証を使う場合は、必ずHTTPS（TLS）と組み合わせ、必要に応じて多要素認証やIP制限なども併用することが重要です。

ベーシック認証
2024.9.3
ベーシック認証とは、ウェブサイトやウェブアプリケーションへのアクセス制限をかけるための基本的な認証方式です。主にユーザー名とパスワードによるシンプルな認証方法であり、Webサーバー側で簡単に設定できるため、多くのウェブサービスやサイトで広く

よくある質問（FAQ）

Q. Base64は暗号化ですか？

いいえ、Base64は暗号化ではありません。Base64はデータの「形を変える」だけで「内容を隠す」機能はありません。誰でも1行のコードで元のデータに復元できます。データを保護したい場合はAES・RSAなどの暗号化技術を使用してください。Base64エンコードされたデータを「安全」と思い込むことは危険です。

Q. Base64エンコードするとデータはなぜ33%増えるのですか？

3バイト（24ビット）のデータが4文字（32ビット相当）のテキストになるためです。8ビットのデータを6ビット単位で扱う変換のため、(4/3 – 1) ≈ 33%のオーバーヘッドが発生します。大量の画像データをBase64で埋め込む際はこの増加分を考慮する必要があります。

Q. 末尾の「=」は何を意味しますか？

「=」はパディング（穴埋め）文字です。Base64は3バイト単位で処理するため、入力データが3の倍数でない場合にブロックを4文字単位に揃えるために追加されます。「=」なし：入力が3の倍数、「=」1つ：余り2バイト、「==」2つ：余り1バイトです。

Q. 標準Base64とBase64URLの違いは何ですか？

Base64URLは「+」を「-」に、「/」を「_」に置き換え、「=」のパディングを省略したURLとファイル名に安全なBase64の派生形式です（RFC 4648 §5）。JWT・OAuth・Web APIなどURL内でBase64を使う場面で標準Base64をそのまま使うと「+」がスペース、「/」がパスの区切りとして解釈されるため問題が発生します。

Q. Base64でエンコードされたデータを安全にデコードするには？

信頼できるソースからのデータのみデコードしてください。特に不明なメール・Webサイト・ファイルに含まれるBase64文字列のデコードは危険です。デコード結果が実行ファイル（.exe・.dll・バイナリなど）だった場合は絶対に実行しないでください。企業環境ではBase64のデコードを含むコンテンツはサンドボックスでの検査を推奨します。

まとめ

Base64は、バイナリデータを64種類のASCII文字からなるテキストに変換するエンコーディング方式です。メール添付ファイル・HTTP通信・Web開発・認証情報の転送・SSL証明書など、現代のインターネットインフラの至る所で使われています。

仕組みとしては3バイト（24ビット）を6ビット×4グループに分割し、各グループをBase64アルファベットの1文字に変換します。これによりデータ量は約33%増加します。URLでの使用にはURL-safe Base64（Base64URL）を使い、「+」→「-」「/」→「_」「=」を省略することで問題を回避します。

Base64は暗号化ではないため、セキュリティ保護の目的では使用できません。一方でBase64はマルウェアの隠蔽・シグネチャ検知の回避・フィッシング攻撃に悪用されるリスクもあるため、不明なBase64文字列のデコードや実行には十分な注意が必要です。

関連コラム（あわせて、以下の記事もよく読まれています）

製品・サービス（当該コラムの内容に関連する製品・サービスはこちら）

SNSでもご購読できます。