Supabase stänger av äldre TLS-kryptering – kontrollera integrationerna

Vad Supabase ändrar

Supabase har meddelat att äldre krypteringsalternativ inom TLS 1.2 ska tas bort från projektens HTTP-API:er. Enligt Supabase changelog kan ändringen genomföras tidigast den 10 november 2026.

TLS är det säkerhetslager som används när en klient ansluter till en adress över HTTPS. Innan ett API-anrop skickas kommer klienten och servern överens om hur anslutningen ska krypteras. Den överenskommelsen kallas en TLS-handskakning.

En cipher suite är en uppsättning tekniska regler för krypteringen. Supabase tar bort äldre alternativ som använder CBC-läge. De har kända säkerhetssvagheter och kan ge varningar i säkerhetsgranskningar. TLS 1.2 försvinner alltså inte. Inte heller påverkas TLS 1.3. Det är bara en äldre del av alternativen inom TLS 1.2 som tas bort.

Ändringen gäller trafik till projektets vanliga Supabase-domän och eventuella egna domäner. Därmed omfattas anrop till:

• Auth
• Data API
• Storage
• Realtime
• Edge Functions

Direkta anslutningar till Postgres, anslutningar genom Supabase pooler och anrop till Management API omfattas inte av just den här förändringen.

Det viktiga är att identifiera vem som faktiskt öppnar anslutningen. Om en webbläsare anropar Supabase direkt är webbläsaren och användarens operativsystem klienten. Om en serverfunktion anropar Supabase är serverns runtime klienten. Om ett externt system skickar en webhook till en Edge Function är det externa systemets HTTP-klient som måste klara den nya konfigurationen.

Vilka klienter som kan sluta fungera

En klient påverkas bara om den varken kan använda TLS 1.3 eller något av de TLS 1.2-alternativ som Supabase behåller. Moderna webbläsare, aktuella servermiljöer och underhållna HTTP-bibliotek bör därför normalt fortsätta fungera.

Risken finns främst i teknik som inte längre uppdateras:

• äldre operativsystem och webbläsare
• gamla versioner av mobil- eller skrivbordsappar
• inbyggda enheter med låst programvara
• egenhostade integrationer på gamla servrar
• äldre Java-, .NET-, PHP-, Node.js- eller OpenSSL-miljöer
• partnerintegrationer där du inte styr HTTP-klienten
• skript eller schemalagda jobb som har körts oförändrade länge

En Lovable-app som körs i webbläsaren använder normalt webbläsarens TLS-stöd. Det innebär att samma webbapp kan fungera för en användare men misslyckas för en annan som sitter på en mycket gammal enhet.

Kod som körs på Vercel använder i stället TLS-stödet i den servermiljö där funktionen körs. En aktuell runtime är mindre riskfylld än en gammal, fastlåst miljö. Kontrollera ändå vilken runtime projektet faktiskt använder i produktion. Det räcker inte att titta på vad ett nytt projekt skulle få som standard.

För webhooks behöver du skilja på riktningen. Om Stripe eller en annan tjänst anropar din Edge Function är tjänsten klient till Supabase. Om din Edge Function anropar tjänstens API är Supabase inte servern för den anslutningen, och just den här ändringen styr inte den utgående trafiken.

Supabase JavaScript-klient väljer inte ensam vilken cipher suite som används. Det gör vanligtvis den underliggande webbläsaren, operativsystemet eller serverns TLS-bibliotek. Att bara uppdatera paketet supabase-js är därför inte alltid lösningen.

Så testar du innan ändringen

Börja med en inventering av alla vägar in till projektets HTTP-API. Titta inte bara på huvudappen. Auth, filuppladdningar, Realtime, bakgrundsjobb och webhooks kan använda olika klienter.

Skriv ned följande för varje anslutning:

• vilken Supabase-adress som anropas
• vilken funktion eller integration som gör anropet
• om koden körs i en webbläsare, app, server eller extern tjänst
• vilket operativsystem och vilken runtime som används
• vem som ansvarar för att miljön uppdateras
• vilken äldsta klientversion du fortfarande stödjer

Testa därefter de faktiska användarflödena från den äldsta miljö du tänker fortsätta stödja. En lyckad inloggning från din egen moderna dator säger inget om en gammal mobilapp eller ett partnerägt integrationsjobb.

Det finns en viktig fallgrop: ett vanligt test mot Supabase kan lyckas i dag eftersom de äldre alternativen fortfarande erbjuds. Testet måste därför visa att klienten kan ansluta med TLS 1.3 eller med ett modernt alternativ inom TLS 1.2.

Om du har tillgång till OpenSSL kan du köra ett begränsat test från samma server, container eller miljö som integrationen använder:

openssl s_client -connect PROJECT.supabase.co:443 -servername PROJECT.supabase.co -tls1_2 -cipher 'ECDHE+AESGCM:ECDHE+CHACHA20' </dev/null

Byt ut domänen mot projektets riktiga domän. En genomförd handskakning visar att just den OpenSSL-miljön har ett gemensamt modernt alternativ med Supabase. Testet bevisar däremot inte automatiskt att din applikation använder samma bibliotek eller inställningar. Kör därför även ett riktigt API-anrop genom applikationens egen kodväg.

För externa integrationer behöver du ofta fråga leverantören. Be dem bekräfta vilket TLS-stöd deras webhook-klient eller HTTP-klient använder. Fråga också om gamla installationsversioner kan ha en annan konfiguration än deras nuvarande tjänst.

Använd den här checklistan inför testet:

• Alla Supabase-domäner och egna domäner är dokumenterade
• Alla anropande klienter och integrationer är identifierade
• Äldre appversioner som fortfarande används är med i inventeringen
• Serverruntime, operativsystem och TLS-bibliotek är kontrollerade
• Externa leverantörer har bekräftat sitt TLS-stöd
• Kritiska flöden har testats från den äldsta stödda miljön
• Resultaten finns dokumenterade så att testet kan upprepas

Så uppdaterar du utan onödigt driftstopp

Den bästa åtgärden är att uppdatera den berörda klientens operativsystem, runtime eller TLS-bibliotek. Försök inte återaktivera svagare kryptering i Supabase – förändringen sker på plattformens sida och är avsedd att ta bort föråldrade alternativ.

Börja med de miljöer du själv kontrollerar. Uppdatera serverfunktioner, bakgrundsjobb och egenhostade integrationer före klientappar som kräver att användaren installerar en ny version. Testa samma användarflöden före och efter uppdateringen.

För en mobil- eller skrivbordsapp behöver en kompatibel version släppas i god tid. Om gamla appversioner fortfarande kan användas efter ändringen bör du ha en plan för hur de möts av ett begripligt felmeddelande eller uppmanas att uppdatera. Ett rått TLS-fel hjälper sällan användaren att förstå problemet.

Undvik att kombinera TLS-uppdateringen med stora ändringar av autentisering, databasstruktur eller API-format. En avgränsad teknisk förändring är lättare att testa och rulla tillbaka om något annat går fel. Du behöver normalt inte byta Supabase-projekt, API-nycklar eller domän enbart på grund av cipher-ändringen.

Om en gammal klient inte kan uppdateras kan en proxy som du kontrollerar fungera som en tillfällig brygga. Den tar emot klientens äldre anslutning och skapar sedan en modern anslutning till Supabase. Det är dock inte en neutral genväg. Proxyn blir en ny säkerhetsgräns som måste hantera certifikat, autentisering, loggning, hemligheter, kapacitetsbegränsning och incidenter. Använd den bara när klienten verkligen inte kan uppdateras och sätt en plan för att ta bort lösningen.

Rulla ut förändringen stegvis där det är möjligt. Börja med en testmiljö eller en begränsad produktionsväg, verifiera inloggning, dataläsning, filhantering, Realtime och Edge Functions, och fortsätt sedan med resten av trafiken.

Felbilden och vad du bör bevaka

När en TLS-handskakning misslyckas skickas inget vanligt HTTP-anrop. Felet uppstår innan Supabase kan läsa sökväg, headers eller autentisering. Därför kan anropet saknas helt i projektets API-loggar.

Beroende på klient kan felet beskrivas som ett handshake failure, ett SSL-fel, en misslyckad säker kanal eller att version och cipher inte matchar. Om användare rapporterar att appen inte längre kan ansluta samtidigt som Supabase-loggarna är tomma bör du kontrollera klientens nätverks- och TLS-fel.

Bevaka därför mer än Supabase-loggarna:

• felrapportering i webb-, mobil- och skrivbordsappar
• loggar från serverfunktioner och bakgrundsjobb
• leveransloggar hos webhook-leverantörer
• larm för misslyckade inloggningar och uppladdningar
• skillnader mellan nya och äldre klientversioner

Kontrollera också att dina supportinstruktioner skiljer mellan ett TLS-fel och ett vanligt API-fel. Att ändra en databaspolicy eller skapa en ny API-nyckel löser inte en misslyckad handskakning.

Det praktiska målet är inte att kartlägga varje krypteringsdetalj. Du behöver veta vilka system som ansluter, vilken teknik de kör och om de kan skapa en modern HTTPS-anslutning. När den tekniska grunden är kontrollerad kan du lägga mer tid på nästa steg – att få betalande kunder.

Källa: Supabase changelog