「まあ、便利だし…」が命取り！OAuthのリダイレクトURIでワイルドカードを使ってはいけない理由
こんにちは。現場の最前線でセキュリティと向き合っていると、たまに「利便性」という名の悪魔の囁きに負けてしまったコードに出会うことがあります。
その代表格が、OAuth 2.0の認可フローにおける「リダイレクトURIのワイルドカード設定」です。
「サブドメインが多すぎて管理が面倒だから https://.example.com で許可しちゃえ！」なんて設定、していませんか？今日は、なぜそれが「玄関の鍵をわざわざ開けっ放しにして、泥棒に地図を渡すような行為」なのか、身近な例えを交えてお話ししますね。
—
1. OAuthのリダイレクトURIって、そもそも何者？
まずは、OAuthの仕組みを「家の鍵」に例えてみましょう。
あなたがGoogleやSNSのログイン機能を使って、新しいアプリ（サービス）にログインするとします。このとき、アプリは「あなたの代わりにGoogleに『この人は私のユーザーです』と確認してね」と頼みます。
このとき、「確認が終わったら、この住所（リダイレクトURI）に結果を返してね！」と、あらかじめGoogleに教えておく必要があります。
つまり、リダイレクトURIは「信頼できる帰宅場所」なんです。
2. ワイルドカードを使ったらどうなる？（泥棒の侵入経路）
もし、あなたが認可サーバー（Googleなど）に対して、帰宅場所を「https://.example.com/（どこでもいいからexample.comの配下ならOK！）」と伝えたらどうなるでしょうか？
ここで、悪意のある攻撃者が現れます。
1. 攻撃の準備: 攻撃者は https://attacker.example.com という、一見すると本物っぽく見える怪しいサイトを作ります。
2. ワイルドカードの盲点: あなたの認可サーバーは「.example.com にマッチするから、こいつは安全なはず！」と勘違いして、あなたの「認証コード（鍵そのもの）」を攻撃者のサイトへ送ってしまいます。
3. 情報の強奪: 攻撃者は受け取った認証コードを使って、あなたの代わりに本物のサービスへログインし、個人情報を抜き取ったり、アカウントを乗っ取ったりします。
そう、ワイルドカードを許可するということは、「どの部屋の窓からでもいいから、誰でも家に入れてあげる」と言っているのと同じなんです。これでは、防犯もへったくれもありませんよね。
—
3. 「完全一致」という鉄の掟
この攻撃を防ぐための対策は、実はとてもシンプルです。「リダイレクトURIは、一文字たりとも違わない『完全一致』で登録する」こと。これに尽きます。
実務での設定イメージ（ダメな例と良い例）
開発中の設定画面を想像してみてください。
- ❌ やってはいけない設定（ワイルドカード）
許可するリダイレクトURI: https://.example.com/callback
これだと、先ほどの攻撃者のサイトも許可されてしまいます。
- ⭕️ 推奨される設定（完全一致）
許可するリダイレクトURI: https://app.example.com/callback
これなら、登録した場所以外には絶対にコードが渡りません。
—
4. 開発者が今すぐやるべきこと
もし今、あなたのサービスでワイルドカードを使っているなら、今すぐ修正を検討してください。具体的なステップは以下の通りです。
1. ホワイトリストの洗い出し: 今使っているリダイレクトURIをすべて書き出しましょう。「テスト環境用」「本番用」など、必要なものだけを個別に列挙します。
2. 認可サーバーの設定変更: 利用している認証プロバイダー（Auth0, AWS Cognito, Google Cloud Identityなど）の設定画面で、ワイルドカードを削除し、必要なURIを一つずつ追加します。
3. 検証の厳格化: コード側でも、受け取ったリダイレクトURIが登録リストと完全に一致するかをチェックするロジックを入れます。
（参考）簡単なチェックのコード例（擬似コード）
// 許可されたURIのリスト（データベースや設定ファイルで管理）
const allowedUris = [
“https://app.example.com/callback”,
“https://dev.example.com/callback”
];
// ユーザーから送られてきたリダイレクトURI
const requestUri = req.query.redirect_uri;
// 「完全一致」しているか確認する
if (!allowedUris.includes(requestUri)) {
// 一致しなければ、攻撃の可能性があるため処理を拒否！
throw new Error(“不正なリダイレクトURIです。セキュリティ違反の疑いがあります。”);
}
—
まとめ：セキュリティは「面倒くさい」の積み重ね
「ワイルドカードを使えば設定が楽になる」。その気持ちは痛いほど分かります。私もエンジニアですから、作業を効率化したいという欲求は理解できます。
しかし、セキュリティにおいて「楽をする」ことは「リスクを買う」ことと同義です。
今回紹介した「完全一致」の原則は、OAuthだけでなく、あらゆる通信の認可設定において基本中の基本です。最初は手間でも、一つひとつ丁寧に「ここだけが信頼できる場所だ」と明示していくこと。その泥臭い積み重ねこそが、あなたのサービスとユーザーを守る最強の盾になります。
一歩ずつで大丈夫です。まずは今、ご自身の環境の設定画面を開いて、“（アスタリスク）が眠っていないか確認することから始めてみませんか？
コメント