Капанът на AI-разработката: Бързина срещу Сигурност

Нека сме честни — всички сме го правили. Прекарваш следобеда с Lovable, Bolt или Cursor, и до вечеря имаш live URL. Усещането е магично. Платформата поема хостинга, SSL-ът е автоматичен, и ето го — проектът ти е тук.

Но ето неудобната истина, която не ме оставя на мира: бързото пускане не означава сигурно пускане. И след като наблюдавам как vibe coding революцията се разгръща, мисля, че трябва да поговорим какво точно остава на заден план в този pipeline от следобед до URL.

Неотдавнашно проучване сканира 155 vibe-coded приложения, които техни създатели са пуснали публично. Деветдесет и девет все още са били живи и сканируеми. Резултатите? Едновременно окуражаващи и притеснителни — и те трябва да променят начина, по който мислим за pre-launch checklist-ите.

Добрата новина: Secrets си остават скрити

Ето какво ме изненада приятно: само 1% от сканираните приложения са изпуснали реални secret ключове към браузъра.

Няма изложени OpenAI API ключове, догорещи чуждия бюджет. Няма AWS credentials, плаващи в client-side JavaScript. Няма Stripe live ключове, готови да източат банкова сметка.

Това ми казва нещо важно: съвременните AI платформи за кодене са подобрили значително своите defaults-и. Когато създадеш нов проект в Bolt или Replit, платформата те насочва към edge functions за secrets вместо да ги изсипва в browser bundle-а. Това е наистина добър UX дизайн от гледна точка на сигурността.

Но един процент все още е прекалено много. Един изложен ключ може да означава $50,000 сметка от OpenAI, компрометиран AWS акаунт, или Stripe dispute, който да потопи стартъпа ти преди дори да е тръгнал. Не бъди този един процент.

Проблемът със Supabase, за който никой не говори

Ето къде нещата стават наистина tricky.

37% от live vibe-coded приложения включват Supabase anonymous key в своя frontend код. И преди да паникьосваш — това всъщност е очаквано. Supabase е проектиран така. Anon key-ът е предназначен да бъде public; твоята сигурност на данните трябва да идва от Row Level Security (RLS) политики.

Ето проблема: RLS е opt-in. Таблиците започват напълно отворени. И когато vibe code-ваш в 11 вечерта, бягайки да хванеш launch deadline-а си, е изключително лесно да пропуснеш онази отметка.

Всяка таблица с изключен RLS — или по-лошо, със using (true) policy — е врата широко отворена за всеки с този public anon key. Атакуващият не се нуждае да хаква каквото и да било. Той просто... заявява твоята база данни, защото си забравил една настройка.

Не мога да подчертая достатъчно: пасивно сканиране не може да открие RLS misconfigurations. Скенерът вижда само frontend-а. Уязвимостта живее в твоята база данни. Трябва да провериш това ръчно, таблица по таблица, преди да пуснеш в production.

Същият съвет важи за Firebase (която се появи в 4% от сканираните приложения). Security rules не са опционални добавки. Те са целият ти security модел.

Security Headers: Невидимият To-Do List

Ако никога не си мислил за HTTP security headers, не си сам. 91% от сканираните приложения нямат Content-Security-Policy, а 88% могат да бъдат вграждани в iframes на произволни уебсайтове (здрасти, clickjacking).

Тези неща не са екзотични уязвимости. Те са стандартни hardening стъпки, които са best practice от години. Vibe coding pipeline-ът просто... не ги включва по подразбиране.

Ето breakdown-а от сканирането:

• 91% липсва Content-Security-Policy
• 88% липсва X-Frame-Options / frame-ancestors
• 37% липсва X-Content-Type-Options
• 38% липсва Referrer-Policy
• 8% липсва Strict-Transport-Security
• Само 5% са имали всички security headers конфигурирани

Светлата точка? Hosting платформите се грижат за HSTS автоматично, така че това е най-вече покрито. Но CSP gap-ът е значителен. Когато AI-написан компонент рендерира user-generated content или интегрира third-party скриптове, CSP е твоята последна линия на защита. Без такъв, XSS атаките нямат къде да се скрият.

Launch Polish Gap-ът

Ето откритие, за което не очаквах да ме е грижа, но определено ме е: 30% от vibe-coded приложения пускат без Open Graph тагове.

Това означава, че когато някой сподели продукта ти в X (Twitter), Discord или LinkedIn, той се появява като голи URL без preview изображение, без заглавие, без описание. Просто... текст. През 2024 това изглежда аматьорски и убива click-through rates.

Допълнителни launch-day пропуски, открити в сканирането:

• 11% нямат meta description
• 77% нямат sitemap.xml
• Общите оценки по сигурност са средно B-minus (84/100), като само 13% са получили A

Приложенията не са били катастрофи — просто са имали нужда от polish. Същата скорост, която те докарва до launch, е същата скорост, която те кара да забравиш <meta property="og:title">.

Моите 5 Минути Pre-Launch Checklist

След като прегледах това проучване, актуализирах своя personal launch checklist. Ето какво наистина има значение преди да пуснеш този Show HN thread:

1. Издири secrets в своя bundle Търси в изходния си код sk-, sk_live_, service_role, ghp_. Всичко, което съвпада, се ротира незабавно и се мести в edge function или environment variable. Един изложен ключ е достатъчен.

2. Одитирай всяка Supabase или Firebase таблица Отвори своя dashboard. Всяка public таблица се нуждае от RLS. Всяка policy трябва да бъде specific — никога using (true). Read access до една misconfigured таблица може да изложи цялата ти потребителска база данни.

3. Добави тези security headers

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

Започни с Content-Security-Policy-Report-Only ако искаш да тестваш без enforcement. Но го пусни в production.

4. Изключи production source maps Твоите *.map файлове са debugging gold за теб — и за атакуващите. Повечето платформи имат toggle. Премини го в off преди launch.

5. Добави своето Open Graph metadata Минимумум: og:title, og:description, og:image. Твоят launch post заслужава да изглежда добре в timeline.

6. Генерирай sitemap.xml Бъдещият ти SEO себе си ще ти благодари. Повечето платформи го генерират автоматично — провери дали твоята го е направила.

По-Голямата Картина

Ето моя take: vibe coding не е проблемът. Проблемът е gap-ът между "работи на моята машина" и "е production-ready". Традиционните разработчици научиха този gap през години на болезнени deployment-и. Vibe coder-ите го учат по-бързо — което всъщност е добре.

Платформите се подобряват. Defaults-ите стават по-добри. Но докато security hardening не стане толкова автоматичен, колкото SSL сертификатите, отговорността пада върху нас като builders да добавим този петминутен checklist преди launch.

Скоростта на vibe coding е суперсила. Сигурността не трябва да бъде данъкът, който плащаш за нея.

Какъв е твоят pre-launch security routine? Пусни твоите checklist добавки в коментарите — винаги търся начини да подобря моя.