Чи безпечний ваш застосунок на Cursor?

Cursor дає вам справжній контроль (ваш репозиторій, ваші файли, ваш деплой), і це змінює те, де сидить ризик. Ви не гадаєте, що зробив білдер від вашого імені. Ви швидко переглядаєте багато працездатного коду й вирішуєте, що читати уважно.

Ось що гайд за гайдом подає неправильно: саме питання, чи пише ШІ небезпечний код, хибне. Згенерований код пишеться так, щоб задовольнити те, про що ви попросили. «Завантаж замовлення користувача» задовольняється кодом, що завантажує замовлення. У цій фразі не сказано чиї, тож у відповіді немає нічого, що це вирішує, а місце, якому належить це рішення, зовсім не той файл, який ви переглядаєте.

«Працює» і «захищений» – це дві різні перевірки

Сама собою йде лише одна.

Уявіть крамницю. Ваш застосунок є вітриною: кожна побудована вами сторінка вручається кожному відвідувачу цілком, бо браузер не намалює того, чого йому не надіслали. Ваша база даних є складом: окремою будівлею в інтернеті з власним замком і власною адресою.

Коли ви запускаєте застосунок і він працює, ви перевірили вітрину: для вас потрібні речі з'являються на потрібних екранах. Замок ви не перевіряли. До складу можна дістатися напряму, взагалі не проходячи крізь вашу крамницю, і те, що застосунок коректно вантажиться, нічого не каже про те, що він поверне тому, хто оминає парадні двері.

Це та перевірка, яка сама собою не йде в жодному проєкті, ані згенерованому, ані написаному вручну. Пропустити її стає легше, коли код надходить швидше, ніж ви встигаєте його читати.

Сам Cursor це інше питання, ніж застосунок, який ви з ним випустили, і саме його насправді ставить більшість: чи безпечний Cursor AI розглядає, що зберігає редактор, що робить не так код, який він пише, і чому ні те, ні те не дістає до того, що може відкрити незнайомець.

Де в проєкті на Cursor ключі йдуть не так

Майже завжди під час переїзду з сервера у браузер.

Є два різновиди облікових даних, і вони майже однакові на вигляд. Публічний ключ називає ваш проєкт і більше нічого (sb_publishable_… у нових проєктах Supabase, anon у старіших), і його зроблено, щоб жити у браузері. Секретний ключ, sb_secret_… або старіший service_role, ігнорує кожне написане вами правило й може читати та змінювати кожен рядок, який у вас є.

Послідовність, що публікує такий ключ, цілком буденна. Код, який використовував секретний ключ на сервері, переносять у компонент, що виконується у браузері. Значення повертається як undefined, тож змінну перейменовують під той префікс, якого хоче інструмент складання (NEXT_PUBLIC_ у Next.js, VITE_ у Vite), і застосунок починає працювати. Власна документація Vite прямо каже, що робить цей префікс: ці значення пакуються у ваш вихідний код під час складання.

.gitignore тут не рятує. Він керує тим, що потрапляє в репозиторій, а результат складання створюється потім. Якщо хочете напевно знати, який із ваших ключів який, є перевірка на одну хвилину.

Перевірка, що належить базі даних

Row Level Security, якщо ваші дані в Supabase, є перемикачем для кожної таблиці, який рядок за рядком вирішує, кому що читати.

Це і є відповідь на проблему «завантаж замовлення». Замість довіряти кожному запиту в коді, що він фільтрує правильно, база даних відмовляється повертати рядки, на які відвідувач не має права, хоч би що казав запит і хоч би хто його написав. Одне правило, застосоване в єдиному місці, крізь яке має пройти кожен запит.

Дві дрібниці вирішують, чи є вона у вас. Supabase вмикає Row Level Security за замовчуванням для таблиць, створених у Table Editor панелі, і не вмикає для створених виконанням SQL, а саме так їх створює файл міграції. І налаштування лише вмикає перевірку; хто пройде, вирішує політика за ним, а політика може все одно дозволяти всім.

Як перевірити власний проєкт на Cursor приблизно за десять хвилин

Шукайте у власному результаті складання, а не у вихідному коді. Зберіть застосунок, а потім пошукайте у згенерованих файлах service_role, sb_secret_ і sk_live_. Усе, що знайдеться, є опублікованим. Це швидше й чесніше за читання вихідного коду, бо це саме те, що отримують відвідувачі.

Прочитайте свій файл середовища на предмет префіксів. Кожна змінна NEXT_PUBLIC_ чи VITE_ є публічною за задумом. Про кожну спитайте себе, чи надрукували б ви її на головній сторінці.

Відкрийте в Supabase Authentication → Policies. Будь-яку таблицю, у якої Row Level Security показано як вимкнену, може прочитати кожен, у кого є адреса вашого проєкту, а вона у вашому застосунку.

А потім подивіться ззовні. Наше безкоштовне сканування робить цей останній крок за вас: воно читає ваш живий сайт як відвідувач і дає оцінку приблизно за 20 секунд, без акаунта: сканувати застосунок.

Зберіть проєкт і пошукайте в результаті service_role та sk_live_ перш за все інше: це хвилина, і відповідь однозначна. Далі 10-хвилинний чекліст безпеки буде найкоротшим шляхом крізь решту.