SecToolbox β

JWTデコーダー

JWTをその場でデコードしてヘッダー・ペイロード・署名を表示。alg=noneなどの危険パターンも警告します。

このページはトークンを外部送信しません(すべてブラウザ内で処理します)

トークンを入力すると、ここにデコード結果が表示されます。

JWTの仕組み

JWT(JSON Web Token)は、JSON形式のデータをコンパクトな文字列にまとめてやり取りするための仕様です。最もよく使われるJWS形式のJWTは、ヘッダー・ペイロード・署名の3つを、ピリオド(.)で連結した ヘッダー.ペイロード.署名という構造を持ちます。

  • ヘッダー ― 署名に使うアルゴリズム(alg)やトークンの種類(typ)などのメタ情報を持ちます。
  • ペイロード ― ユーザーIDや有効期限(exp)など、伝えたい情報(クレーム)が入ります。
  • 署名 ― ヘッダーとペイロードを鍵で署名した値で、内容が改ざんされていないかを検証側が確認するためのものです。

ここで特に誤解されやすいのが、ヘッダーとペイロードは暗号化されていないという点です。これらは Base64URL というエンコード(文字列の符号化)で表現されているだけで、暗号化ではありません。Base64URLは鍵を必要とせず誰でも元に戻せるため、トークンを持っている人は誰でも中身を読めます。署名が果たすのは「改ざんされていないことの検知」であって、「中身を見えなくすること」ではありません。したがって、パスワードなどの秘密情報をペイロードに入れてはいけません。

このデコーダーでトークンを貼り付けると、3つの部分に分けてBase64URLをデコードし、中身を表示します。これらの処理はすべてあなたのブラウザの中だけで行われ、トークンが外部に送られることはありません。

診断士が見るJWTの脆弱パターン

JWTそのものは適切に使えば安全に機能しますが、実装や運用の仕方によっては認証を回避されるリスクがあります。脆弱性診断の現場でよく確認される代表的なパターンを挙げます。多くは「検証側がアルゴリズムや鍵をトークンの言いなりにしている」ことが原因です。

alg: none(署名なしを許容してしまう)

なぜ危険か: JWSの仕様には署名を付けない「none」アルゴリズムが存在する。検証側が受け入れるalgを固定せず、トークン内のalg値を信用していると、攻撃者はalgを none に書き換え署名部分を削除したトークンを送れる。サーバーがこれを有効とみなせば、ペイロード(ロールやユーザーIDなど)を自由に改ざんできてしまう。

対策: サーバー側で許可するアルゴリズムを明示的に固定(allowlist)し、none を拒否する。多くのライブラリは検証時に期待algを渡せるので、トークン任せにしない。

弱いシークレット(HMAC系の総当たり)

なぜ危険か: HS256/384/512 などHMAC系は共有シークレットの強度がすべて。シークレットが短い文字列や辞書語だと、トークンを1つ入手した攻撃者がオフラインで総当たり・辞書攻撃を行い、シークレットを特定できる。判明すれば任意のトークンを正規の署名付きで偽造できる。

対策: 十分な長さ(目安として256ビット以上)のランダムなシークレットを使う。秘密情報をソースコードやリポジトリに含めない。鍵管理を厳格にし、可能なら公開鍵方式(RS256/ES256)も検討する。

alg混同攻撃(RS256 → HS256)

なぜ危険か: サーバーがRS256(公開鍵で検証する非対称方式)を想定しているのに、検証処理がアルゴリズムをトークン任せにし、かつ鍵として公開鍵をそのまま渡している場合に成立する。攻撃者はalgをHS256に書き換え、公開されているRSA公開鍵を「HMACのシークレット」として署名する。サーバーは同じ公開鍵でHMAC検証してしまい、偽造トークンが通る。

対策: 検証時に期待するアルゴリズムを固定する。鍵と検証アルゴリズムを実装上しっかり紐付け、非対称方式の公開鍵がHMACのシークレットとして使われない構造にする。

kid インジェクション

なぜ危険か: ヘッダーの kid(Key ID)で検証鍵を選ぶ実装において、kid の値を検証せずファイルパスやSQLクエリに連結すると、パストラバーサルやSQLインジェクションにつながる。中身が既知・固定のファイルを鍵として指定させ、攻撃者が同じ値で署名できてしまう例もある。

対策: kid は許可リストや内部のマップ経由でのみ鍵に解決する。kid をファイルパス・クエリ・コマンドへ直接連結しない。想定外の kid は拒否する。

署名を検証していない実装ミス

なぜ危険か: デコードだけ行い署名検証を呼んでいない(例: verify ではなく decode のみ使用)、あるいは検証エラーを握りつぶしているケース。この場合、改ざんされたトークンのペイロードをそのまま信用してしまう。exp(有効期限)や aud/iss を確認していない実装も同類の問題を抱える。

対策: 必ず署名検証を行い、検証に失敗したトークンは確実に拒否する。署名に加えて exp・nbf・iss・aud などのクレームも検証し、エラーを握りつぶさない。

なお、このツールはalg=noneなど一部の危険パターンを参考として警告表示しますが、警告が出ないことはトークンや実装の安全性を保証するものではありません。実際の安全性は、サーバー側の検証実装や鍵の管理も含めて総合的に判断する必要があります。

よくある質問(FAQ)

JWTは暗号化されているのですか?

いいえ。一般的に使われるJWT(JWS形式)は暗号化されておらず、ヘッダーとペイロードはBase64URLでエンコードされているだけです。Base64URLは可逆な変換なので、トークンを持っている人は誰でも中身を読めます。中身を秘匿したい場合はJWE(暗号化方式)という別の仕様を使います。

ペイロードに入れた情報は他人から隠せますか?

隠せません。ペイロードは誰でもデコードして読めるため、パスワードや個人情報などの機密をそのまま入れてはいけません。署名はあくまで「改ざんされていないこと」を検知するためのもので、中身を秘匿する仕組みではありません。

署名の検証が通れば、そのトークンは安全だと考えてよいですか?

署名検証は「トークンが改ざんされていないこと」「発行者の鍵で署名されたこと」を確認する重要な手段ですが、それだけで全体の安全が保証されるわけではありません。受け入れるアルゴリズムの固定、exp・nbf・iss・aud などのクレーム検証、鍵の管理、失効の設計なども併せて必要です。

JWTはlocalStorageとCookieのどちらに保存すべきですか?

用途次第で一概には言えません。localStorageはJavaScriptから読めるためXSSがあると盗まれやすく、HttpOnly属性付きのCookieはJSから読めずXSS耐性が高い一方でCSRF対策(SameSite属性など)が必要になります。アプリの要件と脅威モデルに応じて選びます。

このデコーダーに貼り付けたトークンは外部に送信されますか?

いいえ。本ツールはすべてブラウザ内(クライアントサイド)で処理し、トークンや入力したシークレットを外部サーバーへ送信しません。デコード結果はtextContentで描画しているためHTMLとして解釈されず、トークン内の文字列によるスクリプト実行(XSS)も防いでいます。とはいえ本番で使う秘密のトークンの取り扱いには十分ご注意ください。

関連ツール

エンコード変換器 準備中

Base64 / URLエンコード / HTMLエンティティ / Hex などを一括変換。SHA-256等のハッシュ計算にも対応。

セキュリティヘッダー診断 準備中

自分のサイトのレスポンスヘッダーをA〜Fで採点。CSPやHSTSの推奨設定例つき。

CSPビルダー 準備中

Content-Security-PolicyをGUIで組み立て・解析。unsafe-inline等の危険設定は診断士視点で警告します。