← Strona główna← Home← Startsida← Hjem
Autentykacja nie działa w aplikacji zbudowanej przez AI

Każdy użytkownik widzi dane wszystkich innych. Sesje wygasają losowo. OAuth nie przekierowuje. Dlaczego narzędzia AI nie radzą sobie z bezpieczeństwem.

⏱ 5 min czytania

Authentication Not Working in AI-Generated Apps

Every user can see everyone else's data. Sessions expire randomly. OAuth doesn't redirect. Why AI tools fail at security.

⏱ 5 min read
Autentisering fungerar inte i AI-genererade appar

Varje användare kan se alla andras data. Sessioner löper ut slumpmässigt. OAuth omdirigerar inte. Varför AI-verktyg misslyckas med säkerhet.

⏱ 5 min läsning
Autentisering fungerer ikke i AI-genererte apper

Hver bruker kan se alle andres data. Sesjoner utløper tilfeldig. OAuth omdirigerer ikke. Hvorfor AI-verktøy feiler på sikkerhet.

⏱ 5 min lesing

Zero uprawnień — domyślny stan AI-generowanych aplikacji Zero permissions — the default state of AI-generated apps Noll behörigheter — standardläget i AI-genererade appar Null tillatelser — standardtilstanden i AI-genererte apper

Aplikacje generowane przez AI mają jedną wspólną cechę: brak jakichkolwiek reguł prywatności. Każdy zalogowany użytkownik widzi dane każdego innego użytkownika. Narzędzia AI po prostu tego nie konfigurują — bo nikt o to nie prosi.

Większość założycieli nie odkrywa tego, dopóki ktoś nie zwróci im uwagi — albo dopóki nie wydarzy się coś wstydliwego. Klient loguje się do aplikacji i widzi zamówienia, dane kontaktowe i notatki innych klientów. To nie jest edge case. To domyślne zachowanie.

Supabase Auth, NextAuth, Firebase Auth — narzędzia AI podpinają te systemy szybko. Logowanie działa. Ale sesje wygasają losowo, OAuth nie przekierowuje poprawnie po logowaniu, tokeny się nie odświeżają. Użytkownik jest „zalogowany" przez 10 minut, potem musi logować się ponownie. Albo odwrotnie — jest zalogowany na zawsze, nawet po wylogowaniu.

AI-generated apps share one thing in common: zero privacy rules. Every logged-in user can see every other user's data. AI tools simply don't configure this — because nobody asks for it.

Most founders don't discover this until someone points it out — or until something embarrassing happens. A customer logs in and sees orders, contact details, and notes belonging to other customers. This isn't an edge case. It's the default behavior.

Supabase Auth, NextAuth, Firebase Auth — AI tools wire these up quickly. Login works. But sessions expire randomly, OAuth doesn't redirect properly after login, tokens don't refresh. The user is "logged in" for 10 minutes, then has to log in again. Or the opposite — they stay logged in forever, even after logging out.

AI-genererade appar har en sak gemensamt: inga integritetsregler alls. Varje inloggad användare kan se alla andra användares data. AI-verktyg konfigurerar helt enkelt inte detta — för ingen ber om det.

De flesta grundare upptäcker inte detta förrän någon påpekar det — eller tills något pinsamt händer. En kund loggar in och ser beställningar, kontaktuppgifter och anteckningar som tillhör andra kunder. Det här är inget undantagsfall. Det är standardbeteendet.

Supabase Auth, NextAuth, Firebase Auth — AI-verktyg kopplar in dessa snabbt. Inloggning fungerar. Men sessioner löper ut slumpmässigt, OAuth omdirigerar inte korrekt efter inloggning, tokens uppdateras inte. Användaren är "inloggad" i 10 minuter, sedan måste de logga in igen. Eller tvärtom — de förblir inloggade för evigt, även efter utloggning.

AI-genererte apper har en ting til felles: null personvernregler. Hver innlogget bruker kan se alle andres data. AI-verktøy konfigurerer rett og slett ikke dette — fordi ingen ber om det.

De fleste grunnleggere oppdager ikke dette før noen peker det ut — eller til noe pinlig skjer. En kunde logger inn og ser bestillinger, kontaktdata og notater som tilhører andre kunder. Dette er ikke et kanttilfelle. Det er standardoppførselen.

Supabase Auth, NextAuth, Firebase Auth — AI-verktøy kobler opp disse raskt. Innlogging fungerer. Men sesjoner utløper tilfeldig, OAuth omdirigerer ikke riktig etter innlogging, tokens oppdateres ikke. Brukeren er "innlogget" i 10 minutter, så må de logge inn igjen. Eller omvendt — de forblir innlogget for alltid, selv etter utlogging.

Dlaczego bezpieczeństwo nie może być „na potem" Why security can't be an afterthought Varför säkerhet inte kan vara en eftertanke Hvorfor sikkerhet ikke kan komme i etterkant

Prawdziwa historia: deweloper dostał zlecenie na wdrożenie RBAC (Role-Based Access Control) w aplikacji, która miała dosłownie zero uprawnień. Oszacował pracę na 2 tygodnie. Zarząd powiedział: „Ten gość od AI mówi, że zrobi to w 1-2 dni." Dali mu dzień przed produkcyjnym wdrożeniem.

Odmówił. Powiedział, że byłoby nieetyczne udawać, że można zabezpieczyć aplikację w jeden dzień, jeśli wymaga to solidnej pracy. I miał rację — bezpieczeństwo to nie feature, który „dokleja się" na koniec. To fundament, który musi istnieć od początku.

Narzędzia AI potrafią podłączyć logowanie. Ale logowanie to nie bezpieczeństwo. Bezpieczeństwo to Row-Level Security w bazie danych, to poprawne zarządzanie sesjami, to polityki dostępu na endpointach. AI tego nie konfiguruje, bo to wymaga rozumienia, kto ma widzieć jakie dane — a to jest pytanie biznesowe, nie techniczne.

True story: a developer was asked to implement RBAC (Role-Based Access Control) on an app with literally zero permissions. He estimated 2 weeks. Management said: "The AI guy says he can do it in 1-2 days." They gave him the day before production release.

He refused. Said it would be unethical to pretend you can secure an application in one day when it requires real work. And he was right — security isn't a feature you bolt on at the end. It's a foundation that must exist from the start.

AI tools can wire up login. But login is not security. Security is Row-Level Security in the database, proper session management, access policies on endpoints. AI doesn't configure these because it requires understanding who should see which data — and that's a business question, not a technical one.

Sann historia: en utvecklare fick i uppdrag att implementera RBAC (Role-Based Access Control) i en app med bokstavligen noll behörigheter. Han uppskattade arbetet till 2 veckor. Ledningen sa: "AI-killen säger att han kan göra det på 1-2 dagar." De gav honom dagen innan produktionsrelease.

Han vägrade. Sa att det vore oetiskt att låtsas att man kan säkra en applikation på en dag när det kräver ordentligt arbete. Och han hade rätt — säkerhet är inte en funktion man bultar fast i slutet. Det är en grund som måste finnas från början.

AI-verktyg kan koppla in inloggning. Men inloggning är inte säkerhet. Säkerhet är Row-Level Security i databasen, korrekt sessionshantering, åtkomstpolicyer på endpoints. AI konfigurerar inte dessa eftersom det kräver förståelse för vem som ska se vilken data — och det är en affärsfråga, inte en teknisk fråga.

Sann historie: en utvikler fikk i oppdrag å implementere RBAC (Role-Based Access Control) på en app med bokstavelig talt null tillatelser. Han estimerte 2 uker. Ledelsen sa: "AI-fyren sier han kan gjøre det på 1-2 dager." De ga ham dagen før produksjonsrelease.

Han nektet. Sa det ville være uetisk å late som om man kan sikre en applikasjon på en dag når det krever skikkelig arbeid. Og han hadde rett — sikkerhet er ikke en funksjon du bolter på til slutt. Det er et fundament som må finnes fra starten.

AI-verktøy kan koble opp innlogging. Men innlogging er ikke sikkerhet. Sikkerhet er Row-Level Security i databasen, riktig sesjonshåndtering, tilgangspolicyer på endepunkter. AI konfigurerer ikke disse fordi det krever forståelse for hvem som skal se hvilke data — og det er et forretningsspørsmål, ikke et teknisk spørsmål.

Jak naprawić autentykację i uprawnienia How to fix authentication and permissions Så fixar du autentisering och behörigheter Slik fikser du autentisering og tillatelser

  1. Włącz Row-Level Security (RLS). W Supabase to kilka kliknięć. Zdefiniuj polityki: użytkownik widzi tylko swoje dane. Admin widzi wszystko. Bez RLS baza jest otwarta jak księga — każdy zalogowany użytkownik ma dostęp do wszystkiego.
  2. Popraw konfigurację auth. Sprawdź czas wygasania sesji, callback URL-e dla OAuth, odświeżanie tokenów. Te ustawienia muszą być spójne między frontendem a backendem. AI często ustawia je w jednym miejscu, ale zapomina o drugim.
  3. Zabezpiecz endpointy. Każdy endpoint API musi sprawdzać, czy użytkownik jest zalogowany i czy ma uprawnienia do żądanych danych. Nie wystarczy sprawdzić „czy jest token" — trzeba sprawdzić, czy ten token daje dostęp do tych konkretnych danych.
  4. Zdefiniuj role od początku. Kto jest użytkownikiem? Kto adminem? Kto moderatorem? Te role muszą istnieć w bazie danych i być respektowane na każdym poziomie — frontend, API i baza.
Ostrzeżenie

Jeśli Twoja aplikacja jest już w produkcji bez RLS — każdy zalogowany użytkownik prawdopodobnie widzi dane wszystkich innych. To nie jest teoretyczne ryzyko. To aktualny stan Twojej aplikacji.

  1. Enable Row-Level Security (RLS). In Supabase, it's a few clicks. Define policies: a user sees only their own data. An admin sees everything. Without RLS, the database is wide open — every logged-in user has access to everything.
  2. Fix the auth configuration. Check session expiry times, OAuth callback URLs, token refresh. These settings must be consistent between frontend and backend. AI often sets them in one place but forgets the other.
  3. Secure your endpoints. Every API endpoint must verify that the user is logged in and has permission to access the requested data. It's not enough to check "is there a token" — you need to verify that token grants access to this specific data.
  4. Define roles from the start. Who is a user? Who is an admin? Who is a moderator? These roles must exist in the database and be respected at every level — frontend, API, and database.
Warning

If your app is already in production without RLS — every logged-in user can probably see everyone else's data. This isn't a theoretical risk. It's the current state of your application.

  1. Aktivera Row-Level Security (RLS). I Supabase är det några klick. Definiera policyer: en användare ser bara sin egen data. En admin ser allt. Utan RLS är databasen vidöppen — varje inloggad användare har tillgång till allt.
  2. Fixa auth-konfigurationen. Kontrollera sessionens utgångstider, OAuth callback-URL:er, tokenuppdatering. Dessa inställningar måste vara konsekventa mellan frontend och backend. AI ställer ofta in dem på ett ställe men glömmer det andra.
  3. Säkra dina endpoints. Varje API-endpoint måste verifiera att användaren är inloggad och har behörighet att komma åt den begärda datan. Det räcker inte att kontrollera "finns det en token" — du måste verifiera att den tokenen ger tillgång till just den specifika datan.
  4. Definiera roller från början. Vem är användare? Vem är admin? Vem är moderator? Dessa roller måste finnas i databasen och respekteras på varje nivå — frontend, API och databas.
Varning

Om din app redan är i produktion utan RLS — kan varje inloggad användare förmodligen se alla andras data. Det här är inte en teoretisk risk. Det är det aktuella tillståndet i din applikation.

  1. Aktiver Row-Level Security (RLS). I Supabase er det noen klikk. Definer policyer: en bruker ser bare sine egne data. En admin ser alt. Uten RLS er databasen vidåpen — hver innlogget bruker har tilgang til alt.
  2. Fiks auth-konfigurasjonen. Sjekk sesjonsutløpstider, OAuth callback-URL-er, tokenoppdatering. Disse innstillingene må være konsistente mellom frontend og backend. AI setter dem ofte på ett sted, men glemmer det andre.
  3. Sikre endepunktene dine. Hvert API-endepunkt må verifisere at brukeren er innlogget og har tillatelse til å få tilgang til den forespurte dataen. Det er ikke nok å sjekke "finnes det en token" — du må verifisere at den tokenen gir tilgang til akkurat den spesifikke dataen.
  4. Definer roller fra starten. Hvem er bruker? Hvem er admin? Hvem er moderator? Disse rollene må finnes i databasen og respekteres på hvert nivå — frontend, API og database.
Advarsel

Hvis appen din allerede er i produksjon uten RLS — kan sannsynligvis hver innlogget bruker se alle andres data. Dette er ikke en teoretisk risiko. Det er den nåværende tilstanden til applikasjonen din.

Przeczytaj też Read also Läs också Les også

Użytkownicy widzą cudze dane? Users seeing each other's data? Användare ser varandras data? Brukere ser hverandres data?

To pilne. Wdrożymy Row-Level Security, naprawimy sesje i uprawnienia — zanim ktoś jeszcze to zauważy. This is urgent. We'll implement Row-Level Security, fix sessions and permissions — before anyone else notices. Det här är brådskande. Vi implementerar Row-Level Security, fixar sessioner och behörigheter — innan någon annan märker det. Dette haster. Vi implementerer Row-Level Security, fikser sesjoner og tillatelser — før noen andre oppdager det.

Zarezerwuj bezpłatną rozmowę → Book a free call → Boka ett gratis samtal → Bestill en gratis samtale →
Bezpłatna rozmowa Bez zobowiązań Odpowiedź w 24h
Free consultation No obligation Reply within 24h
Gratis konsultation Utan förpliktelser Svar inom 24h
Gratis konsultasjon Helt uforpliktende Svar innen 24t