Vibe coding tətbiqləri təhlükəsizdir? Yoxlanacaq 8 boşluq

Vibe coding ilə yaradılan tətbiqlər təhlükəsizdir?

Defolt olaraq yox: burada göstərilən bütün böyük araşdırmalar yoxladıqları tətbiqlərin böyük hissəsində ciddi təhlükəsizlik boşluqları tapıb ^[3][4][5]. Tətbiqlər adətən işləyir. Problem onların yad şəxslərə nəyə icazə verməsidir.

2026-cı ildə aparılmış bir audit Claude Code və Lovable ilə yaradılmış 9.041 açıq mənbəli tətbiqi toplayıb və onlardan ictimai yayımda olan 200-nü yoxlayıb. Audit 1.186 zəiflik tapıb, 200 tətbiqdən 182-də (91,0%) ən azı biri olub ^[4]. Bu qüsurların 65,77%-i kritik və ya yüksək, o cümlədən 18,47%-i kritik dərəcəli sayılıb ^[4].

Müəlliflər daha yaxşı promptların və agent ayarlarının problemi həll edib-etmədiyini də yoxlayıblar. Onlar problemi azaldıb, amma aradan qaldırmayıb; eyni tapşırıq üç dəfə icra olunanda bir dəfə təhlükəsiz, növbəti dəfə isə təhlükəli nəticə verə bilib ^[4]. Başqa sözlə, bir versiyadakı təmiz nəticə növbəti haqqında az şey deyir.

Metodun əsasları üçün Pouyam bələdçisi Vibe Coding Explained: What It Is, How It Works and the Real Risks-ə baxın. İlk layihə üçün Vibe Coding for Beginners: How to Start Safely in 2026 başlanğıc planı təqdim edir. Bu səhifə bir pillə dərinə gedir: konkret boşluqlar və hər birinin necə yoxlanacağı.

Təhlükəsizlik araşdırmaları vibe coding tətbiqlərində nə tapır?

Dörd müstəqil mənbə eyni zəif nöqtəni göstərir: yanlış şəxsin oxuya və ya dəyişə bildiyi məlumatlar ^[1][3][4][5].

• Yayımdakı 200 tətbiqin auditi (2026): pozulmuş giriş nəzarəti 1.186 qüsurdan 339-u (28,58%) ilə ən böyük kateqoriya olub və tətbiqlərin 64,00%-nə təsir edib. İnyeksiya 54,00%-nə, autentifikasiya xətaları 51,50%-nə təsir edib ^[4].
• ACM CCS 2026 araşdırması: tam tarixçəsi olan 8.641 Lovable repozitoriyasında oxuma qaydalarının 11,2%-i sistemə daxil olmamış ziyarətçilərə açıq olub, repozitoriyaların 61,2%-də isə ən azı bir belə qayda olub. Təkrar test seçilmiş 400 repozitoriyadan 353-də ifşanı təsdiqləyib ^[5].
• Escape (oktyabr 2025): Lovable, Base44 və Create.xyz kimi platformalarda yaradılmış 5.600-dən çox ictimai tətbiqin passiv skanı 2.000-dən çox zəiflik, 400-dən çox ifşa olunmuş gizli məlumat və tibbi qeydlər, IBAN-lar (bank hesabı identifikatorları), telefon nömrələri və e-poçtlar daxil olmaqla 175 şəxsi məlumat halı tapıb ^[3].
• CVE-2025-48757 (2025): 21 mart 2025-ci ildə başa çatan skan 1.645 Lovable layihəsindən 170-də, təxminən 10,3%-də, qeyri-kafi sətir qaydaları olan 303 verilənlər bazası son nöqtəsi tapıb ^[1].

Escape vurğulayır ki, skan heç bir dağıdıcı əməliyyat aparmayıb, ona görə rəqəmlər minimumdur; daha dərin test daha çox şey tapardı ^[3]. Eyni ehtiyat buradakı bütün rəqəmlərə aiddir: bu araşdırmalar kənardan görə bildiklərini sayır.

Süni intellekt alətləri niyə təhlükəli tətbiqlər yaradır?

Çünki alətlər işləyən tətbiqə yönəlir, təhlükəsizlik qaydaları isə promptda nadir hallarda yazılan biznes detallarından asılıdır ^[4][11].

İşləyən kodu yoxlamaq asandır: səhifə açılır, düymə işləyir. Hər qeydi kimin görə biləcəyi isə biznes qərarıdır və heç kim bunu yazmasa, alət təxmin etməli olur. 2026-cı il auditi qüsurları süni intellekt agentlərinin üç məhdudiyyəti üzrə qruplaşdırılan səkkiz təkrarlanan xəta modelinə bağlayır: yaddaş, məqsədlər və bilik ^[4].

Süni intellekt modellərinin geniş testləri eyni boşluğu göstərir. Veracode-un GenAI Code Security Report 2026 hesabatı öz testlərində kod yaratma tapşırıqlarının təxminən 44%-nin təhlükəsizlik zəifliyi gətirdiyini müəyyən edib ^[11]. AWS-in istinad etdiyi benchmark-a görə, 12 agent ayarından ən yaxşısı tapşırıqların 57%-ni düzgün həll edib, lakin yalnız 11,8%-ni həm düzgün, həm də təhlükəsiz həll edib ^[10].

Bir çox vibe coding tətbiqi həm də təhlükəsizliyi verilənlər bazasına keçirir. Brauzer birbaşa host edilən bazaya müraciət edir, ona görə bazanın qaydaları ziyarətçi ilə hər sətir arasında yeganə maneədir ^[1][6]. Qaydalar yoxdursa və ya çox genişdirsə, ünvanı bilən hər kəs hər şeyi istəyə bilər.

Əvvəlcə hansı 8 təhlükəsizlik boşluğunu yoxlamalıyam?

Araşdırmaların ən çox tapdığı boşluqlardan başlayın və onları vura biləcəkləri zərərə görə sıralayın ^[1][3][4][5].

1. Açıq baza qaydaları: row level security olmayan və ya hər ziyarətçiyə bütün sətirləri oxumağa imkan verən qaydaları olan cədvəllər. CVE-2025-48757-nin və ACM tapıntılarının kökü bu idi ^[1][5].
2. Pozulmuş giriş nəzarəti: sistemə daxil olmuş istifadəçi ünvandakı və ya sorğudakı ID-ni dəyişərək başqasının qeydini açır. Bu, 2026-cı il auditinin ən böyük kateqoriyası idi ^[4].
3. Brauzerdə gizli açarlar: frontend koduna qoyulmuş Supabase secret və ya service_role açarı, ödəniş açarı və ya süni intellekt provayderinin açarı. Escape 400-dən çox ifşa olunmuş gizli məlumat tapıb ^[3][6].
4. Çatışmayan və ya zəif giriş yoxlamaları: sessiya olmadan cavab verən şəxsi səhifələr və ya API marşrutları. Autentifikasiya xətaları yoxlanılan tətbiqlərin 51,50%-nə təsir edib ^[4].
5. İnyeksiya: istifadəçi daxiletməsinin yoxlanılmadan sorğulara və ya HTML-ə çatması; yoxlanılan tətbiqlərin 54,00%-də aşkar edilib ^[4].
6. Yazıla bilən cədvəllər: ziyarətçilərə təkcə oxumağa deyil, məlumat əlavə etməyə və ya dəyişməyə imkan verən qaydalar. CVE halında giriş tokeni olmayan sorğu "ödənilib" kimi işarələnmiş qeyd əlavə edib və ödəniş mərhələsini keçib ^[1].
7. Artıq məlumat qaytaran cavablar: səhifəyə yalnız ad lazım olduğu halda bütöv istifadəçi qeydlərini, e-poçtları və ya tokenləri qaytaran API-lər. Escape 175 ifşa olunmuş şəxsi məlumat halı sayıb ^[3].
8. Riskli agent girişi: istehsal mühitinin giriş məlumatlarına malik kodlaşdırma agenti real zərər vura bilər; 2025-ci ilin iyulunda bir agent kodun dondurulduğu dövrdə canlı verilənlər bazasını silib ^[10].

1-4-cü boşluqlar kənar hücumçuların istismar etdiklərinin çoxunu əhatə edir, ona görə onları hər şeydən əvvəl yoxlayın.

Vibe coding tətbiqimi bu boşluqlara qarşı necə yoxlayım?

Tətbiqdən hücumçu kimi istifadə edin: yad şəxs kimi, ikinci istifadəçi kimi və brauzerin aldığını oxuyaraq ^[1][4][5]. Bu addımların heç biri xüsusi alət tələb etmir.

1. İki test hesabı yaradın. A hesabı ilə qeyd yaradın, onun ünvanını və ya ID-sini kopyalayın, B hesabı ilə daxil olun və onu açmağa, redaktə etməyə və silməyə çalışın. Alınırsa, giriş nəzarəti pozulub ^[4].
2. Sistemdən çıxıb təkrarlayın. Eyni ünvanları sessiyasız gizli pəncərədə açın. CVE halında giriş başlığını silmək bütün yoxlamaları keçmək üçün kifayət edib ^[1].
3. Şəbəkə tabını izləyin. Brauzerin tərtibatçı alətlərində səhifənin hər sorğusuna və qayıdan cavaba baxın. Cavablarda yalnız həmin ekrana lazım olan olmalıdır, heç vaxt başqa istifadəçilərin e-poçtları və ya tokenləri yox ^[3].
4. Səhifə kodunda açar axtarın. sb_secret_ ilə başlayan sətirləri, service_role etiketini və ya ödəniş, süni intellekt kimi provayder açarlarını axtarın. Publishable açar gözləniləndir; secret açar isə təcili haldır ^[6].
5. Hər cədvəlin qaydalarını yoxlayın. Baza panelində hər cədvəldə row level security-nin aktiv olduğunu təsdiqləyin və hər qaydanı sadə dillə oxuyun: kim oxuya bilər, kim yaza bilər ^[7].
6. Qeyri-adi daxiletmələr sınayın. Hər formaya çox uzun mətn, dırnaq işarələri və HTML teqləri yapışdırın və tətbiqin çöküb-çökmədiyini və ya onları kod kimi göstərib-göstərmədiyini yoxlayın ^[4].

Yalnız sizə məxsus və ya yoxlamağa icazəniz olan tətbiqləri test edin. Başqalarının tətbiqlərini yazılı icazə olmadan yoxlamayın.

Açıq Supabase qaydalarını və sızan açarları necə düzəldim?

Hər cədvəldə row level security-ni aktiv edin, dar qaydalar yazın, gizli açarları serverdə saxlayın və sızan hər açarı dəyişin ^[6][7][8].

• Row level security-ni hər yerdə aktiv edin. Supabase-in bələdçisi onu açıq sxemdəki hər cədvəldə aktiv etməyi deyir ^[7]. Aktiv edildikdən sonra siz qayda əlavə edənədək ictimai açar heç nəyə çatmır ^[7].
• Defolt icazələri silin. Bunları hələ də defolt olaraq verən layihələrdə yeni ictimai cədvəl daxil olmamış (anon) və daxil olmuş (authenticated) rollara artıq verilmiş bütün imtiyazlarla başlayır və qayda əlavə etmək bu icazələri geri almır ^[7]. Onları ləğv edin və hər rola yalnız lazım olanı geri verin ^[7].
• Qaydaları istifadəçiyə görə yazın. Şəxsi cədvəlin qaydası sadəcə daxil olmuş hər kəsə icazə verməməli, daxil olmuş istifadəçinin ID-si ilə uyğunlaşmalıdır. Həssas cədvəllərdə həmişə doğru olan qaydalardan qaçın ^[2].
• Gizli açarları server tərəfində saxlayın. Supabase-in publishable açarı brauzerdə yalnız sətir qaydaları onu məhdudlaşdırdığı üçün təhlükəsizdir; secret və service_role açarları bütün qaydaları keçir və server kodunda və ya təhlükəsiz mühit ayarlarında qalmalıdır ^[6].
• Sızan açarları yeniləyin. Gizli açar nə vaxtsa brauzerə və ya ictimai kod repozitoriyasına düşübsə, onu yeniləyin və sızmış açarı deaktiv edin; Supabase-in açar bələdçisi də bunu məsləhət görür ^[6].

2026-cı il noyabrın 15-nə olan məlumata görə, Supabase-in sənədləri köhnə anon və service_role açarlarının 2026-cı ilin sonunadək publishable və secret açarlar xeyrinə ləğv edildiyini bildirir ^[8]. Yeni secret açarlar brauzerdə istifadə olunanda xəta (HTTP 401) qaytarır, lakin sızmış açardan yenə də başqa alətlərdən istifadə etmək olar ^[6][8]. İndi keçid etmək tətbiqin istifadə etdiyi hər açarı yoxlamaq üçün yaxşı fürsətdir.

Daxili təhlükəsizlik skanerləri hər şeyi tutur?

Xeyr: platforma skanerləri kömək edir, lakin bir neçə araşdırma onların ən vacib qaydaları buraxdığını göstərir ^[1][2][5].

2025-ci ildə CVE-2025-48757-ni aşkar edən tədqiqatçılar müəyyən ediblər ki, Lovable-ın skaneri yalnız sətir qaydasının olub-olmadığını yoxlayırdı, düzgün olub-olmadığını yox ^[1]. Onların xəbərdarlığında əlavə olunur ki, Lovable-ın yayım yoxlaması qaydasız cədvəlləri qeyd edir, lakin qaydaların kifayət qədər sərt olub-olmadığını göstərmir ^[2]. Açıq qayda belə yoxlamadan keçir.

ACM araşdırması bunu rəqəmlərlə göstərir: altı alət üzrə 6,3% kimi mülayim açıq qayda payı belə repozitoriyaların 56,9%-ni ən azı bir açıq cədvəllə qoyub, çünki bir açıq qayda kifayətdir ^[5]. Müəlliflər belə qaydaları commit-dən əvvəl qeyd edən pulsuz yoxlayıcı yayımlayıblar ^[5].

Skanerlərdən ilk filtr kimi istifadə edin, sonra iki hesablı və sistemdən çıxılmış testləri özünüz aparın. Aşağıdakı cədvəl rəqəmləri ümumiləşdirir.

Başqalarının vibe coding ilə yaratdığı tətbiqlərdən istifadə təhlükəsizdir?

Şəxsi, sağlamlıq və ya ödəniş məlumatı istəyən hər şeyə qarşı ehtiyatlı olun, çünki istifadəçilər tətbiqin bu məlumatları necə qoruduğunu görə bilmir ^[3][4]. Escape ifşa olunmuş məlumatlar arasında tibbi qeydlər və IBAN-lar (bank hesabı identifikatorları) tapıb ^[3].

Bəzi sadə vərdişlər riski azaldır. Hər yeni tətbiq üçün ayrıca parol istifadə edin ki, bir sızıntı digər hesabları açmasın; bunun yolunu Pouyam bələdçisi Password Managers Explained: How They Work and Whether They Are Safe izah edir. Tətbiqə yalnız lazım olan məlumatları verin və tətbiq daxilindəki formalardan çox tanınmış ödəniş provayderlərinin ödəniş səhifələrinə üstünlük verin.

Əsas məsuliyyət tətbiqi yaradanların üzərindədir. Başqalarının məlumatlarını saxlayan tətbiq yayımlayırsınızsa, yuxarıdakı yoxlamaları yayımdan əvvəl və hər böyük dəyişiklikdən sonra aparın, çünki tək bir yeni funksiya bağlanmış boşluğu yenidən aça bilər ^[4][5].