---
title: "Supabase leaked password protection: hvad den blokerer"
description: "Hvad Supabase leaked password protection tjekker, hvorfor den kræver Pro-planen, hvor ofte almindelige adgangskoder står i lækager, og hvad du sætter uden den."
url: "https://madsalt.tech/da/notes/supabase-leaked-password-protection/"
author: "Denys Zaichenko"
author_url: "https://madsalt.tech/da/about/"
language: "da"
published: 2026-10-30
---

# Supabase leaked password protection: hvad den blokerer

TL;DR

Leaked password protection får Supabase Auth til at afvise adgangskoder, der findes i Have I Been Pwned-lækagekorpuset. Den er tilgængelig fra Pro-planen og opefter. Den 23. oktober 2026 indeholdt korpuset `password123` 2.266.543 gange, og min lokale Supabase Auth med standardindstillinger accepterede den ved tilmelding. Den vurderer ikke styrke: `Lovable2026!` forekom 0 gange. Slå den til, hvor du kan, og sæt en længere minimumslængde under alle omstændigheder.

Mit gratis [Supabase sikkerhedstjek](https://madsalt.tech/da/tools/supabase-security-check/) læser et projekts Auth-indstillinger, og "Beskyttelse mod lækkede adgangskoder slået fra" er en af dets regler, ved siden af "Kort minimumslængde for adgangskoder". Denne note forklarer, hvad indstillingen faktisk tjekker, med tal, jeg hentede fra den samme tjeneste, den bruger.

## Hvad er leaked password protection i Supabase?

Det er en af adgangskodeindstillingerne i dit projekts Auth-indstillinger i Dashboard. Når den er slået til, tjekker Supabase Auth hver ny adgangskode mod tjenesten [Pwned Passwords](https://haveibeenpwned.com/Passwords) fra Have I Been Pwned og afviser dem, der findes dér. Supabases [guide til adgangskodesikkerhed](https://supabase.com/docs/guides/auth/password-security) nævner den sammen med minimumslængde og krævede tegn og bemærker, at den er tilgængelig fra Pro-planen og opefter.

Tjekket sender aldrig adgangskoden. Pwned Passwords bruger en k-anonymity-intervalforespørgsel: klienten hasher adgangskoden med SHA-1, sender kun de første 5 tegn af hashen og sammenligner de returnerede suffikser lokalt.

## Hvor ofte står almindelige adgangskoder i lækager?

Jeg kørte selv den samme intervalforespørgsel den 23. oktober 2026 for nogle få adgangskoder, jeg ser i testkonti og AI-genererede seed-data:

![Hvor ofte hver adgangskode optræder i kendte lækager. Pwned Passwords range API, 23. oktober 2026. qwerty123: 13.871.714; password123: 2.266.543; Password1!: 584.516; Welcome1!: 239.099; Summer2026!: 45; supabase123: 7; Lovable2026!: 0.](https://madsalt.tech/charts/da/supabase-leaked-password-protection.svg)

*Kilde: Have I Been Pwned, Pwned Passwords range API, forespurgt 23. oktober 2026.*

| Adgangskode    | Antal gange set i lækager |
| -------------- | ------------------------- |
| `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` er udeladt af diagrammet, fordi den ville flade alle de andre søjler ud. De sidste tre rækker er pointen: en adgangskode kan mangle i alle lækager og stadig være nem at gætte. Leaked password protection stopper credential stuffing med kendte adgangskoder. Den måler ikke styrke.

## Hvad sker der uden den?

På en lokal Supabase (CLI 2.109.1, Auth v2.192.0) med standardindstillinger tilmeldte jeg en testbruger med `password123`. Auth svarede `200` og oprettede brugeren. Det eneste, den afviste, var en adgangskode på 5 tegn, med `422 weak_password` og årsagen `length`, fordi det lokale standardminimum er 6 tegn.

Uden indstillingen står der altså intet mellem en bruger og en adgangskode, der er lækket millioner af gange, bortset fra længdereglen.

## Hvad bør du sætte?

1. **På Pro og opefter:** slå leaked password protection til. Eksisterende brugere kan stadig logge ind, og ifølge guiden får dem, hvis adgangskode ikke opfylder de nye krav, en `WeakPasswordError`, der forklarer hvorfor, så du kan bede dem skifte.
2. **På alle planer:** hæv minimumslængden. Guiden kalder alt under 8 tegn ikke anbefalet; reglen i mit tjek foreslår 12 eller flere.
3. **Kræv tegnklasser** kun hvis dine brugere kan leve med det; længde gør mere end et påkrævet symbol.
4. **Tilføj MFA** til konti, der betyder noget, og kræv den nuværende adgangskode eller en reauthentication nonce for at skifte adgangskode; begge dele står i den samme guide.

Leaked password protection er en af flere Auth-indstillinger, der kun findes i det hostede projekts konfiguration, ikke i dit repo. Resten af det, jeg tjekker på en Supabase-app, fra RLS til rate limits på login, står i min [sikkerhedstjekliste til Lovable-apps](https://madsalt.tech/da/blog/lovable-app-security-checklist/), og hvad Supabase dækker, og hvad der er dit, står i [er Supabase sikkert](https://madsalt.tech/da/blog/is-supabase-secure/).