Har din Lovable- eller Supabase-nyckel hamnat på GitHub?

Vad GitHub faktiskt har ändrat

GitHub utökade i oktober 2026 sin secret scanning med stöd för fler typer av hemligheter från Lovable och Supabase. Secret scanning söker efter kända format för API-nycklar, åtkomsttoken och andra autentiseringsuppgifter som har hamnat i ett repository.

Enligt GitHubs changelog känner GitHub nu igen Lovables API-nycklar samt Supabase OAuth-token och avgränsade personliga åtkomsttoken. Det gäller alltså inte bara filerna i den senaste versionen av projektet. GitHub söker även i Git-historik, grenar och innehåll runt pull requests och ärenden. När stöd för en ny typ av hemlighet läggs till kan äldre kod därför ge utslag.

Detektorerna fungerar inte likadant för alla leverantörer. Lovable deltar i GitHubs partnerprogram. När en stödd Lovable-nyckel hittas i ett publikt repository kan GitHub rapportera den direkt till Lovable. Lovable anger att exponerade API-nycklar som börjar med lov_ då spärras automatiskt och att workspace-ägaren meddelas.

Det betyder att du inte nödvändigtvis får en vanlig varning i GitHub först. Ett integrationsjobb kan i stället sluta fungera eftersom nyckeln redan har återkallats.

För de nya Supabase-formaten skapar GitHub en secret scanning-varning när repositoryts inställningar och GitHub-plan ger stöd för det. I publika repositories sker GitHubs grundläggande scanning automatiskt. För privata repositories behöver du kontrollera vilka säkerhetsfunktioner som är aktiverade i organisationen.

Det viktiga är att se detekteringen som ett skyddsnät, inte som en säkerhetsmodell. En angripare eller automatiserad söktjänst kan hitta nyckeln innan GitHub, leverantören eller du själv hinner reagera.

Alla Supabase-nycklar är inte hemliga

Ordet nyckel skapar lätt fel slutsats. Vissa nycklar är avsedda att finnas i klientkod, medan andra ger privilegierad åtkomst och aldrig får nå webbläsaren.

Supabase skiljer mellan publicerbara nycklar och hemliga nycklar. Den publicerbara nyckeln identifierar din app men ger bara den åtkomst som databasens behörigheter och Row Level Security tillåter. Den kan därför användas i en webbläsare. Den äldre anon-nyckeln har motsvarande klientroll.

En Supabase secret key eller äldre service_role-nyckel är något helt annat. Den används i betrodd backendkod och kan kringgå Row Level Security. Om den hamnar i klientkod eller Git-historik ska den behandlas som komprometterad.

De Supabase-token som lades till i GitHubs uppdatering är främst till för Supabase Management API:

• Scoped personal access token används av exempelvis CLI, CI-flöden, MCP-servrar och automatisering. Token kan begränsas till utvalda projekt och behörigheter.
• OAuth access token används när en integration agerar åt en Supabase-användare efter ett godkännande.

Det här är inte samma sak som den publicerbara nyckel som din frontend använder för att läsa data genom Supabase-klienten. Uppdateringen innebär alltså inte att varje synlig Supabase-nyckel är en incident.

Det avgörande är vad uppgiften kan göra:

En publicerbar nyckel gör inte databasen säker av sig själv. Säkerheten ligger i tabellbehörigheter, RLS-policyer och kontroller av den inloggade användaren. Om en anonym användare kan läsa eller ändra allt är problemet databaskonfigurationen, inte att den publicerbara nyckeln syns.

Varför klientkod och miljöfiler blir fällor

Kod som körs i webbläsaren är offentlig i praktiken. En besökare kan läsa JavaScript-filer, nätverksanrop och värden som har byggts in i applikationen. Det gäller även om repositoryt är privat.

Variabelnamn med prefix som VITE_ eller NEXT_PUBLIC_ signalerar normalt att värdet ska skickas till klienten. Prefixet skyddar ingenting. Det gör motsatsen – byggverktyget gör värdet tillgängligt i webbläsaren.

Det här är rimligt för en Supabase-URL och en publicerbar Supabase-nyckel. Det är fel för en Lovable API-nyckel, Supabase secret key, service_role, Stripe secret key eller en personlig åtkomsttoken.

.env är inte heller automatiskt ett säkert valv. Det är bara ett filformat för konfiguration. Säkerheten beror på om filen committas, vilka variabler som byggs in i klienten och var appen körs.

Lovable har dessutom ett arbetssätt som skiljer sig från många traditionella projekt. Lovables dokumentation anger att projektets .env ska finnas i repositoryt eftersom VITE_-värden behövs för preview och publicerade byggen. Den filen får därför bara innehålla värden som tål att bli offentliga.

Privata värden i Lovable ska i stället lagras i Secrets och användas av Edge Functions eller andra serverfunktioner. De injiceras vid körning och skickas inte till webbläsaren. På Vercel ska motsvarande värden läggas i projektets miljövariabler utan publikt prefix och bara läsas av serverkod.

Vanliga läckor uppstår när du:

• klistrar in en riktig nyckel i kod för att snabbt testa en integration
• döper en hemlig variabel med ett publikt klientprefix
• committar en lokal miljöfil innan .gitignore är rätt konfigurerad
• lägger nyckeln i ett exempel, en logg eller ett felmeddelande
• skickar en nyckel i en prompt, kommentar eller pull request
• återanvänder samma privilegierade nyckel i flera tjänster
• flyttar ett serveranrop till frontend för att lösa ett CORS- eller autentiseringsproblem

En bra tumregel är att webbläsaren bara ska anropa din egen backend när en extern tjänst kräver en hemlig nyckel. Backendfunktionen läser hemligheten från plattformens secret manager, kontrollerar användaren och gör sedan anropet vidare.

Gör detta om en nyckel har läckt

Att radera raden och göra en ny commit räcker inte. Nyckeln kan finnas kvar i Git-historiken, gamla byggen, cachar, loggar och lokala kopior. Utgå från att en committad hemlighet redan har kopierats.

Följ den här ordningen:

• Identifiera exakt vilken typ av nyckel det är. Kontrollera leverantör, behörighet, miljö och vilka system som använder den.
• Spärra eller återkalla den gamla nyckeln. Vänta inte på att koden ska städas. Om Lovable redan har spärrat nyckeln ska du verifiera statusen i workspace-inställningarna.
• Skapa en ersättare med mindre behörighet. Använd separata nycklar för olika integrationer och begränsa projekt, scopes, giltighet och tillåtna IP-adresser där tjänsten stödjer det.
• Uppdatera alla beroenden. Byt värdet i Lovable Secrets, Supabase, Vercel, GitHub Actions och andra miljöer som använder nyckeln.
• Distribuera om berörda tjänster. En uppdaterad miljövariabel hjälper inte alltid en redan byggd klient eller pågående process.
• Kontrollera att den gamla nyckeln inte längre fungerar. Testa utan att återaktivera den eller lägga tillbaka den i kod.
• Granska loggar och aktivitet. Leta efter oväntade API-anrop, ändrade projektinställningar, nya användare, databasfrågor eller publiceringar från tiden efter exponeringen.
• Ta bort hemligheten ur koden. Flytta anropet till serverkod och använd plattformens secret manager.
• Bedöm om Git-historiken behöver skrivas om. Det kan vara motiverat om värdet fortfarande förekommer i sökningar eller om repositoryt ska delas vidare, men omskrivning ersätter aldrig spärrning.

För en läckt Supabase personal access token ska du radera token och skapa en ny med avgränsade rättigheter. Om en Supabase secret key eller service_role har läckt behöver du rotera projektets servernyckel och kontrollera dataåtkomst. Om ett OAuth-godkännande har komprometterats behöver kopplingen återkallas så att tillhörande token inte kan förnyas.

Stäng inte GitHub-varningen som falsklarm bara för att filen har raderats. Dokumentera vilken nyckel som spärrades, var ersättaren lagras och vilka kontroller du gjorde.

Bygg en rutin som fångar nästa misstag

Secret scanning är mest värdefullt när det ingår i ett enkelt arbetssätt. Kontrollera GitHubs Security-vy, aktivera tillgängligt skydd mot att pusha hemligheter och kör Lovables säkerhetsscanning efter förändringar i integrationer eller backendkod.

Gör också en manuell genomgång av variablerna i projektet:

• Vilka värden är avsedda att vara publika?
• Vilka variabler har VITE_ eller NEXT_PUBLIC_?
• Finns någon servernyckel i frontendkoden?
• Har Supabase-tabeller med klientåtkomst fungerande RLS-policyer?
• Använder CI-flöden avgränsade token i stället för kontoövergripande åtkomst?
• Har varje integration en egen nyckel som kan spärras utan att resten av systemet stannar?
• Finns gamla nycklar kvar i Git-historik, exempel eller dokumentation?
• Vet du vem som ansvarar för att reagera på säkerhetsvarningar?

Det viktiga skiftet är att sluta tänka på miljövariabler som automatiskt privata. Fråga i stället var värdet används, var koden körs och vilka rättigheter uppgiften ger. Då blir det tydligare vad som kan ligga i klienten och vad som måste stanna på serversidan.

När en snabb Lovable-prototyp börjar hantera riktiga användare, data och integrationer behöver även nyckelhanteringen följa med i arbetet från prototyp till produkt.

---

Källa: GitHub changelog