Wyciek danych Moltbook: Kiedy programowanie wibracjami staje się koszmarem bezpieczeństwa

Co tak naprawdę wydarzyło się na Moltbook?

Pozwól, że rozłożę na czynniki pierwsze, co poszło nie tak, ponieważ szczegóły mają znaczenie.

Moltbook został zbudowany przy użyciu Supabase — popularnej alternatywy open-source dla Firebase, która zapewnia hostowane bazy danych PostgreSQL. Supabase stał się backendem wyboru dla aplikacji tworzonych z pomocą AI, ponieważ obsługuje uwierzytelnianie, bazy danych i przechowywanie z minimalną konfiguracją.

Problem? Ktoś (lub jakiś AI) umieścił klucz API Supabase bezpośrednio w kodzie JavaScript po stronie klienta. To fundamentalny błąd bezpieczeństwa. Klucze API należą do serwera, nigdy nie powinny znajdować się w kodzie działającym w przeglądarce użytkownika.

Ale jest gorzej.

Ten klucz API miał pełny dostęp do odczytu i zapisu do całej bazy danych. I Moltbook nie włączył Row Level Security (RLS) — funkcji Supabase, która kontroluje, kto ma dostęp do jakich danych. RLS jest tak samo opcjonalna jak pas bezpieczeństwa. Możesz myśleć, że nie potrzebujesz go, dopóki nie wypadniesz.

Badacze bezpieczeństwa z Wiz znaleźli odsłonięty klucz w ciągu minut od obejrzenia strony. Mogli:

• Pobrano 1,5 miliona kluczy API (w tym klucze dla OpenAI, Anthropic i innych dostawców AI)
• Dostęp do prywatnych wiadomości między agentami AI
• Zmodyfikowano lub usunięto dane w bazie danych
• Przejęcie konta dowolnego użytkownika
• Generuj ogromne rachunki za pomocą skradzionych kluczy API

Najważniejsze? Założyciel przyznał, że „całkowicie zbudował platformę za pomocą vibe coding”. Żadnego kodu review. Żadnego audytu bezpieczeństwa. Tylko prompty do AI i kopiowanie-wklejanie wyników.

Dlaczego to się ciągle dzieje?

To jest frustrujące w tej historii: nie jest to unikalne.

Pamiętasz, jak DeepSeek ujawnił swoje klucze API? A Base44? Wzorzec się powtarza, ponieważ filozofia vibe coding aktywnie zniechęca do praktyk, które zapobiegają takim naruszeniom.

Filozofia vibe coding opiera się na: działaj szybko, skup się na wynikach, nie przejmuj się szczegółami. Jest kusząca, ponieważ — szczerze mówiąc — działa przy budowaniu prototypów. Możesz uruchomić działającą aplikację w ciągu godzin.

Ale aplikacje produkcyjne żyją w innym świecie. Obsługują prawdziwe dane użytkowników, prawdziwe płatności, prawdziwe zagrożenia bezpieczeństwa. To samo podejście, które pomaga Ci wydać prototyp w weekend, doprowadzi do włamania Twojej aplikacji produkcyjnej w pierwszym dniu.

Rozmawiałem z badaczem ds. bezpieczeństwa specjalizującym się w kodzie generowanym przez AI. Oto co nie pozwala mu spać spokojnie:

• Nie rozumiesz, co się dzieje: Gdy promptujesz AI do "zbudowania systemu logowania", otrzymujesz kod, który wygląda jak system logowania, ale może mieć subtelne błędy, które zauważy tylko ekspert
• Ufanie AI: Użytkownicy zakładają, że kod wygenerowany przez AI jest bezpieczny, ponieważ... to z AI? To założenie jest całkowicie błędne
• Brak podstaw: Deweloperzy vibe często nie wiedzą, czego nie wiedzą o bezpieczeństwie

Problem 45%

Powiedzę Ci liczbę, która powinna nie dać Ci zasnąć: 45%.

To jest procent kodu generowanego przez AI, który zawiera podatności bezpieczeństwa, według badań Veracode nad bezpieczeństwem oprogramowania generowanego przez AI^[1].

To nie chodzi o złe modele AI lub niekompetentnych programistów. Chodzi o fundamentalną naturę generowania kodu. Modele AI są trenowane na istniejącym kodzie — który zawiera niebezpieczny kod. Powtarzają wzorce, które widziały, w tym podatne na niebezpieczeństwo.

Typowe podatności w kodzie generowanym przez AI obejmują:

Wyciek Moltbook był tak naprawdę dwoma problemami: zakodowanym kluczem API (twardo zakodowane sekrety) AND brak RLS (niebezpieczna konfiguracja). Każdy z nich osobno byłby złym rozwiązaniem. Razem stworzyli katastrofę.

Tego nikt Ci nie powie o Vibe Coding

Powiem Ci to wprost. Wrzucałem w kodowanie z AI sporo projektów. To naprawdę zmieniło sposób, w jaki buduję rzeczy. Ale nauczyłem się też niektórych trudnych lekcji na własnej skórze.

Wciąż musisz zrozumieć bezpieczeństwo

Oto nieprzyjemna prawda: nie możesz używać narzędzi AI do budowania bezpiecznych aplikacji, jeśli sam nie rozumiesz bezpieczeństwa. AI nie zna Twojego modelu zagrożeń. Nie wie, jakie aktywa chronisz. Po prostu generuje kod, który wygląda rozsądnie.

Nie musisz stawać się ekspertem od bezpieczeństwa. Ale musisz rozumieć:

• Nigdy nie umieszczaj sekretów w kodzie po stronie klienta
• Zawsze włączaj zabezpieczenia na poziomie wiersza w bazach danych
• Używaj zmiennych środowiskowych do wrażliwej konfiguracji
• Wdrażaj prawidłową walidację danych wejściowych
• Uruchamiaj skanery bezpieczeństwa na wygenerowanym kodzie

Prototypuj szybko, potem inżynieruj

Mój obecny przepływ pracy:

• Vibe code prototyp — Uruchom coś działającego, zweryfikuj pomysł z prawdziwymi użytkownikami
• Zidentyfikuj dopasowanie produkt-rynek — Zanim zainwestujesz cokolwiek
• Refaktoryzacja na produkcję — To jest moment, w którym faktycznie inżynierujesz bezpieczeństwo, wydajność i łatwość utrzymania

Błąd polega na wypychaniu prototypów zaprojektowanych pod kątem klimatu bezpośrednio do produkcji bez kroku refaktoringu. Nie oszczędzasz czasu — gromadzisz dług techniczny, który potem Cię kosztować będzie.

Użyj odpowiedniego narzędzia do pracy

To może być kontrowersyjne, ale nie sądzę, że vibe coding jest odpowiednie dla:

• Aplikacje obsługujące wrażliwe dane użytkownika (zdrowie, finanse)
• Systemy przetwarzające płatności
• Cokolwiek z wymaganiami dotyczącymi zgodności regulacyjnej
• Aplikacje, w których błędy bezpieczeństwa mogą spowodować realne szkody

Dla narzędzi wewnętrznych, MVP i prototypów? Rób co chcesz. Dla systemów produkcyjnych obsługujących prawdziwe dane użytkowników? Zaprojektuj je właściwie.

Jak się chronić

Jeśli i tak vibe coding (i szczerze, powinieneś — to niezwykle potężne), oto jak unikać bycia następnym nagłówkiem:

Dla Twojego Supabase/Backend

javascript
// WRONG - Never do this
const supabase = createClient('https://xxx.supabase.co', 'YOUR_ANON_KEY_HERE')
// Your service_role key is also exposed here!

// CORRECT - Use environment variables, server-side only
const supabase = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_ANON_KEY
)

Podstawowa lista kontrolna bezpieczeństwa

• [ ] Włącz Ochronę Poziomu Wiersza na WSZYSTKICH tabelach bazy danych
• [ ] Przechowuj klucze API w zmiennych środowiskowych, nigdy w kodzie
• [ ] Uruchom skanowanie bezpieczeństwa wygenerowanego kodu (Snyk, CodeQL lub GitHub Advanced Security)
• [ ] Nigdy nie ujawniaj kluczy service_role po stronie klienta
• [ ] Wdróż prawidłową walidację danych wejściowych dla wszystkich danych od użytkownika
• [ ] Skonfiguruj limity szybkości, aby zapobiec nadużyciom
• [ ] Zdobądź test penetracyjny przed uruchomieniem czegokolwiek z prawdziwymi użytkownikami

Narzędzia, które pomagają

Co to oznacza dla branży

Jestem szczerze martwy o to, dokąd zmierzamy.

Jesteśmy w środku ogromnej zmiany w sposobie, w jaki oprogramowanie jest tworzone. Nie-techniczni założyciele mogą teraz tworzyć zaawansowane aplikacje. Bariera wejścia runęła. To naprawdę ekscytujące.

Ale tworzymy też pokolenie aplikacji, nad którymi nikt nie czuwa w sklepie.

Oto co, moim zdaniem, powinno się stać:

• Narzędzia AI do kodowania potrzebują lepszych domyślnych ustawień bezpieczeństwa — Przestań generować kod z wbudowanymi podatnościami
• Społeczność musi o tym mówić więcej — Każdy wpis blogowy o vibe coding powinien wspomnieć o bezpieczeństwie
• Potrzebujemy lepszych narzędzi — Automatyczne skanowanie bezpieczeństwa powinno być wbudowane w każdy przepływ pracy AI do kodowania
• Twórcy muszą przejąć odpowiedzialność — Nie możesz obwiniać AI, gdy coś pójdzie nie tak

Przyszłość rozwoju oprogramowania nie polega na wyborze między szybkością AI a bezpieczeństwem. To nauka korzystania z obu razem.

Najczęściej zadawane pytania

Podsumowanie

Moltbook nie jest anomalią. To zapowiedź tego, co nadchodzi.

W miarę jak więcej twórców wypuszcza aplikacje stworzone z pomocą AI bez zrozumienia podstaw bezpieczeństwa, będziemy mieli więcej naruszeń. Więcej wyciekających kluczy API. Więcej odsłoniętych baz danych. Więcej ofiar.

To nie jest argument przeciwko vibe coding. To argument za uczciwością co do jego ograniczeń.

Wysyłaj szybko. Testuj pomysły. Poruszaj się szybko. Ale zanim postawisz dane użytkowników w zagrożeniu, zwolnij i wykonaj pracę nad bezpieczeństwem. Twoi użytkownicy ufają Ci ze swoimi informacjami. Zaufanie nie powinno być vibe-coded.

Powiązane posty

• Czym Jest Vibe Coding? Kompletny Przewodnik 2026
• Cursor vs Windsurf do Vibe Coding: Kto wygrywa w 2026?
• Jak zbudować aplikację AI w 7 dni (krok po kroku)
• Jak Szybko Zebrać 100 Beta Użytkowników

Gotowy bezpiecznie uruchomić swoją aplikację? Wypisz swoją aplikację na GetFree—kuratednym katalogu, w którym deweloperzy udostępniają kody promocyjne i dostęp beta tysiącom celowanych testerów.

Źródła

Oryginalnie opublikowano na Blog GetFree.APP — Ostatnia aktualizacja: 17 lutego 2026