Ukryte długi bezpieczeństwa aplikacji AI: Co 155 wdrożeń zdradziło

Pułapka Prędkości w Developmentzie Napędzanym AI

Bądźmy szczerzy — wszyscy to robiliśmy. Spędziliśmy popołudnie na pingowaniu Lovable, Bolta czy Cursora i do kolacji mieliśmy działającą stronę. Wyglądało to jak magia. Platforma ogarnęła hosting, SSL działał automatycznie, a nasz mały projekt nagle stał się prawdziwy.

Ale jest niewygodna prawda, do której ciągle wracam: szybka publikacja nie oznacza bezpiecznej publikacji. I jako ktoś, kto obserwuje rewolucję vibe codingu, myślę że powinniśmy porozmawiać o tym, co ta rurka „od popołudnia do URL-a" tak naprawdę zostawia za sobą.

Ostatnie głębokie zanurzenie w temat przeskanowało 155 aplikacji stworzonych metodą vibe coding, które ich twórcy udostępnili publicznie. Dziewięćdziesiąt dziewięć wciąż działało i dawało się przeskanować. Wyniki? Równie zachęcające co niepokojące — i powinny zmienić nasze podejście do checklist przed startem.

Dobra Wiadomość: Sekrety Pozostają Sekretami

Oto co mile mnie zaskoczyło: tylko 1% przeskanowanych aplikacji wyciekało prawdziwe klucze sekretne do przeglądarki.

Żadnych wystawionych kluczy API OpenAI, które paliły budżet kogoś innego. Żadnych poświadczeń AWS pływających w client-side JavaScript. Żadnych aktywnych kluczy Stripe gotowych do opróżnienia konta bankowego.

To mówi mi coś ważnego: nowoczesne platformy AI do kodowania naprawdę poprawiły swoje domyślne ustawienia. Kiedy tworzysz nowy projekt w Bolcie czy Replit, platforma prowadzi cię w stronę edge functions dla sekretów zamiast wrzucać je do browser bundla. To naprawdę dobry UX design pod kątem bezpieczeństwa.

Ale jeden procent to wciąż jeden procent za dużo. Jeden wystawiony klucz to rachunek OpenAI na 50 tysięcy dolarów, przejęte konto AWS albo spór ze Stripe, który zatopi twój startup zanim jeszcze wystartuje. Nie bądź tym jednym procentem.

Problem Supabase, O Którym Nikt Nie Mówi

Oto gdzie robi się naprawdę ciekawie.

37% działających aplikacji vibe-coded zawiera anonimowy klucz Supabase w kodzie frontendowym. I zanim spanikujesz — to jest właściwie oczekiwane. Supabase jest tak zaprojektowany. Anon key jest publiczny; bezpieczeństwo twoich danych ma pochodzić z polityk Row Level Security (RLS).

Problem wygląda tak: RLS jest opcjonalne. Tabele startują całkowicie otwarte. A kiedy o 23:00 kodujesz z feelingiem, goniąc deadline, niezwykle łatwo przeoczyć tego checkboxa.

Każda tabela z wyłączonym RLS — albo gorzej, z leniwą polityką using (true) — to otwarte drzwi dla każdego, kto ma ten publiczny anon key. Atakujący nie musi nic hakować. Po prostu... wysyła zapytania do twojej bazy, bo zapomniałeś jednego ustawienia.

Nie mogę tego podkreślić dość mocno: pasywne skanowanie nie wykryje błędnych konfiguracji RLS. Skaner widzi tylko frontend. Podatność mieszka w twojej bazie danych. Musisz to sprawdzić ręcznie, tabela po tabeli, zanim wystartujesz.

Ta sama rada dotyczy Firebase (które pojawiło się w 4% przeskanowanych aplikacji). Reguły bezpieczeństwa nie są opcjonalnymi dodatkami. To cały model bezpieczeństwa.

Nagłówki Bezpieczeństwa: Niewidoczna Lista Zadań

Jeśli nigdy nie myślałeś o nagłówkach bezpieczeństwa HTTP, nie jesteś sam. 91% przeskanowanych aplikacji nie ma Content-Security-Policy, a 88% można osadzić w iframe na dowolnej stronie (cześć, clickjacking).

To nie są egzotyczne podatności. To standardowe kroki hardeningu, które od lat są najlepszą praktyką. Rurka vibe codingu po prostu... ich nie zawiera domyślnie.

Oto rozbicie ze skanowania:

• 91% brakuje Content-Security-Policy
• 88% brakuje X-Frame-Options / frame-ancestors
• 37% brakuje X-Content-Type-Options
• 38% brakuje Referrer-Policy
• 8% brakuje Strict-Transport-Security
• Tylko 5% miało wszystkie nagłówki bezpieczeństwa skonfigurowane

Jasny punkt? Platformy hostingowe obsługują HSTS automatycznie, więc to jest w większości covered. Ale luka CSP jest znacząca. Kiedy komponent napisany przez AI renderuje treść od użytkowników albo integruje skrypty third-party, CSP to twoja ostatnia linia obrony. Bez niego ataki XSS nie mają gdzie się ukryć.

Luka w Polish枣 przed Startem

Oto odkrycie, którego nie spodziewałem się, że będzie mnie obchodzić, a jednak kompletnie mnie zainteresowało: 30% aplikacji vibe-coded startuje bez tagów Open Graph.

To znaczy, że kiedy ktoś dzieli się twoim produktem na X (Twitterze), Discordzie czy LinkedIn, pokazuje się goły URL bez obrazka podglądu, bez tytułu, bez opisu. Po prostu... tekst. W 2024 wygląda to amatorsko i zabija click-through rates.

Dodatkowe przeoczenia dnia startu znalezione w skanowaniu:

• 11% nie miało meta description
• 77% nie miało sitemap.xml
• Średnia ocen bezpieczeństwa to B-minus (84/100), tylko 13% dostało A

Aplikacje nie były katastrofami — po prostu potrzebowały polishu. Ta sama prędkość, która daje ci launch, jest tą samą prędkością, która sprawia, że zapominasz o <meta property="og:title">.

Moja 5-Minutowa Checklist Przed Startem

Po przeczytaniu tego badania zaktualizowałem swoją osobistą checklistę launchową. Oto co naprawdę ma znaczenie zanim wrzucisz ten wątek na Show HN:

1. Wytrop sekrety w swoim bundlu Przeszukaj zbudowany output pod kątem sk-, sk_live_, service_role, ghp_. Cokolwiek pasuje, rotuj natychmiast i przenieś do edge function albo zmiennej środowiskowej. Jeden wystawiony klucz wystarczy.

2. Audytuj każdą tabelę Supabase lub Firebase Otwórz dashboard. Każda publiczna tabela potrzebuje włączonego RLS. Każda polityka musi być konkretna — nigdy using (true). Read access do jednej źle skonfigurowanej tabeli może narazić całą bazę użytkowników.

3. Dodaj te nagłówki bezpieczeństwa

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Zacznij od Content-Security-Policy-Report-Only jeśli chcesz testować bez enforcementu. Ale wdaj to.

4. Wyłącz produkcyjne source maps Twoje pliki *.map to złoto debugowania dla ciebie — i dla atakujących. Większość platform ma toggle. Przestaw na off przed startem.

5. Dodaj meta dane Open Graph Minimum: og:title, og:description, og:image. Twój post launchowy zasługuje na ładny wygląd w timeline.

6. Wygeneruj sitemap.xml Twój przyszły SEO-sam sobie podziękuje. Większość platform generuje je automatycznie — sprawdź czy twoja to zrobiła.

Szerszy Obrazek

Oto moje zdanie: vibe coding nie jest problemem. Problemem jest luka między „działa na mojej maszynie" a „jest gotowe na produkcję". Tradycyjni deweloperzy nauczyli się tej luki przez lata bolesnych deploymentów. Vibe coderzy uczą się jej szybciej — co właściwie jest dobre.

Platformy się poprawiają. Domyślne ustawienia są lepsze. Ale dopóki hardening bezpieczeństwa nie będzie tak automatyczny jak certyfikaty SSL, odpowiedzialność spoczywa na nas jako builderach, żeby dodać tę pięciominutową checklistę przed startem.

Prędkość vibe codingu to supermoc. Bezpieczeństwo nie musi być podatkiem, który za nią płacisz.

Jaka jest twoja rutyna bezpieczeństwa przed startem? Wrzucaj swoje dodatki do checklisty w komentarzach — zawsze szukam jak ją usprawnić.