---
title: "Supabase leaked password protection：何を防ぐのか"
description: "Supabaseのleaked password protectionが何を確認するか、なぜProプランが必要か、よくあるパスワードが漏えいにどれだけ現れるか、使えない場合の設定を紹介します。"
url: "https://madsalt.tech/ja/notes/supabase-leaked-password-protection/"
author: "Denys Zaichenko"
author_url: "https://madsalt.tech/ja/about/"
language: "ja"
published: 2026-10-30
---

# Supabase leaked password protection：何を防ぐのか

TL;DR

leaked password protectionは、Have I Been Pwnedの漏えいデータに含まれるパスワードを、Supabase Authに拒否させる設定です。Proプラン以上で使えます。2026年10月23日時点で、このデータには`password123`が2,266,543回含まれていましたが、デフォルト設定の私のローカルSupabase Authは、サインアップでそれを受け付けました。強度は判定しません。`Lovable2026!`は0回でした。使える場合はオンにし、使えない場合でも最小文字数を長くしてください。

私の無料の[Supabaseセキュリティチェッカー](https://madsalt.tech/ja/tools/supabase-security-check/)は、プロジェクトのAuth設定を読み取ります。ルールの1つが「漏えいパスワードの保護がオフ」で、「パスワードの最小文字数が短い」と並んでいます。このノートでは、この設定が実際に何を確認するのかを、同じサービスから取った数字で説明します。

## Supabaseのleaked password protectionとは？

DashboardのAuth設定にある、パスワード関連の設定の1つです。オンにすると、Supabase Authは新しいパスワードをHave I Been Pwnedの[Pwned Passwords](https://haveibeenpwned.com/Passwords)サービスで確認し、そこで見つかったものを拒否します。Supabaseの[パスワードセキュリティのガイド](https://supabase.com/docs/guides/auth/password-security)は、最小文字数や必須文字種と並べてこの設定を挙げ、Proプラン以上で使えると書いています。

この確認では、パスワードそのものは送信されません。Pwned Passwordsはk-匿名性のレンジクエリを使います。クライアントがパスワードのSHA-1ハッシュを計算し、ハッシュの先頭5文字だけを送り、返ってきたサフィックスをローカルで照合します。

## よくあるパスワードは、漏えいにどれだけ現れる？

2026年10月23日に、同じレンジクエリを自分で実行しました。テストアカウントやAIが生成したシードデータでよく見るパスワードをいくつか選んでいます。

![各パスワードが既知の漏えいに現れた回数。Pwned Passwords range API、2026年10月23日。qwerty123：13,871,714、password123：2,266,543、Password1!：584,516、Welcome1!：239,099、Summer2026!：45、supabase123：7、Lovable2026!：0。](https://madsalt.tech/charts/ja/supabase-leaked-password-protection.svg)

*出典：Have I Been PwnedのPwned Passwords range API、2026年10月23日に照会。*

| パスワード     | 漏えいで確認された回数 |
| -------------- | ---------------------- |
| `123456`       | 210,461,208            |
| `qwerty123`    | 13,871,714             |
| `password123`  | 2,266,543              |
| `Password1!`   | 584,516                |
| `Welcome1!`    | 239,099                |
| `Summer2026!`  | 45                     |
| `supabase123`  | 7                      |
| `Lovable2026!` | 0                      |

`123456`は、ほかのすべての棒をつぶしてしまうので、グラフから外しました。大事なのは最後の3行です。パスワードはどの漏えいにも含まれていなくても、推測されやすいことがあります。leaked password protectionが防ぐのは、既知のパスワードによるクレデンシャルスタッフィングです。強度を測るものではありません。

## この設定がないとどうなる？

デフォルト設定のローカルSupabaseスタック（CLI 2.109.1、Auth v2.192.0）で、テストユーザーを`password123`でサインアップしました。Authは`200`を返し、ユーザーを作成しました。拒否したのは5文字のパスワードだけで、`422 weak_password`と理由`length`が返りました。ローカルのデフォルトの最小文字数が6文字だからです。

つまりこの設定がなければ、文字数のルールを除いて、何百万回も漏えいしたパスワードとユーザーの間を遮るものは何もありません。

## 何を設定すべき？

1. **Proプラン以上：** leaked password protectionをオンにします。既存のユーザーはそのままサインインでき、ガイドによると、新しい要件を満たさないパスワードのユーザーには理由を説明する`WeakPasswordError`が返るので、変更を促せます。
2. **すべてのプラン：** 最小文字数を長くします。ガイドは8文字未満を非推奨としており、私のチェッカーのルールは12文字以上を勧めています。
3. **文字種の必須化**は、ユーザーが受け入れられる場合だけにします。必須の記号より、長さのほうが効果があります。
4. **大切なアカウントにはMFA**を追加し、パスワードを変更するときは現在のパスワードか再認証のnonceを要求します。どちらも同じガイドに載っています。

leaked password protectionは、リポジトリではなくホスト版プロジェクトの設定にしか存在しない、いくつかのAuth設定の1つです。RLSからサインインのレート制限まで、Supabaseのアプリで私が確認するそのほかの項目は[Lovableアプリのセキュリティチェックリスト](https://madsalt.tech/ja/blog/lovable-app-security-checklist/)にあり、Supabaseが担当する範囲とあなたの担当の区別は[Supabaseは安全か](https://madsalt.tech/ja/blog/is-supabase-secure/)にあります。