Безпека сайту для вайбкодера: 4 діри, які треба закрити

Що означає «захистити сайт» простими словами

Твій сайт - це дім. Усередині твої речі, дані користувачів, інколи їхні гроші. А тепер уяви, що ти:

• написав пароль від сейфа маркером прямо на вхідних дверях;
• врізав крутий замок, але ключ лишив стирчати в шпарині;
• пускаєш будь-кого, хто буркнув «я свій», навіть не глянувши в обличчя.

Дико? А саме так виглядає сайт, який згенерував ШІ, якщо про безпеку йому не сказали ні слова. Агент за замовчуванням робить так, щоб працювало. Не так, щоб було безпечно. Це два різні завдання, і друге треба просити окремо.

Кому потрібен мій маленький лендинг? Навіщо взагалі захищатися

«Я ж просто роблю лендинг, кому я потрібен?» - найчастіша думка новачка. І найдорожча. А ось як насправді:

• Боти сканують весь інтернет цілодобово. Їм байдуже, хто ти. Вони шукають відчинені двері автоматично - мільйонами на годину.
• Є на сайті форма? Навіть просте «залиште email» - це вже точка входу.
• Витік API-ключ API-ключ - секретний пароль, за яким твій сайт спілкується з іншими сервісами: оплата, розсилки, ШІ. Якщо він витече, чужі будуть витрачати гроші від твого імені. від платного сервісу - і чужі люди палять твої гроші, поки ти солодко спиш.
• А витекли дані користувачів - це вже не «упс». Це штрафи, розборки й репутація в труху.

Гарна новина: гуру кібербезу ставати не треба. Треба знати чотири головні діри й уміти попросити агента їх закрити. Цим і займемося.

Чотири головні діри в безпеці сайту

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

1. Де зберігати API-ключі та паролі (секрети)

Секрет Секрет - будь-який пароль, токен чи ключ: доступ до бази даних, до платіжки, до API. Усе, що дає владу над твоїм сервісом. - це ключ від дому. Правило одне й просте: ключ не валяється всередині дому на видноті.

Так роблять новачки (і так робити НЕ треба):

const apiKey = "sk-proj-xxxxx" - ключ вшитий прямо в код. А код часто живе в гіті. Гіт часто публічний. І все - ключ уже не твій.

А як треба? Ключі лежать в окремому файлі (зазвичай .env.local), а в коді стоїть лише посилання на нього - process.env.OPENAI_API_KEY. І цей файл із ключами обовʼязково вписаний у .gitignore, щоб він ніколи не поїхав у гіт.

2. Перевірка вводу користувача та завантаження файлів

Усе, що вводить користувач - текст у формі, завантажений файл, адреса сторінки - треба перевіряти, перш ніж щось із цим робити. Правило в один рядок: не вір вводу за замовчуванням.

Особливо це стосується завантаження файлів. Є в тебе «завантажте аватарку»? Тоді за чек-листом агент перевіряє три речі:

• розмір - наприклад, не більше 5 мегабайтів. Інакше тобі заллють гігабайтний файл і акуратно покладуть сервер;
• тип - тільки картинки: jpeg, png, gif. А не виконуваний файл-вірус, що прикинувся котиком;
• розширення - .jpg, .png. А не .exe, якому домалювали імʼя картинки.

І ще одне правило з чек-листа: перевіряй за білим списком («можна тільки ось це»), а не за чорним («не можна ось це»). Чорний список завжди дірявий. Ти фізично не перелічиш усе погане на світі, а хакеру вистачить одного пропущеного варіанту.

3. Права доступу: перевіряй на сервері, кому можна

Улюблена пастка новачків: «я просто сховав кнопку видалення від звичайних юзерів - отже, безпечно». Ні. Сховати кнопку - це завісити двері фіранкою. Кнопки не видно, але двері відчинені: хто знає адресу, той увійде.

А як правильно? Перевірка на сервері перед кожною важливою дією. Перш ніж видалити, змінити чи показати чужі дані, код зобовʼязаний спитати: «а в цієї людини взагалі є право?» Наприклад, перед видаленням користувача сервер спершу переконується, що запит іде від адміна, і лише потім щось чіпає.

4. Безпечні помилки й логи: не базікай зайвого

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

І дзеркальне правило: у логи не повинні потрапляти секрети. Не логуй паролі, номери карток, CVV і токени. Витече такий лог - і ти сам віддаси хакеру все на тарілочці з блакитною облямівкою.

Безпечний сайт проти дірявого: порівняння

Як зламують сайт: приклад із життя

Зібрав ти з агентом сайт-магазинчик: каталог, форма замовлення, завантаження фото товару, оплата через сторонній сервіс. Усе працює, ти задоволений, заливаєш на GitHub і публікуєш. А через два дні:

1. Прилітає рахунок від платіжки на купу грошей - бо ключ лежав прямо в коді, і боти виловили його з твого публічного репозиторію.
2. Сервер ледь дихає - хтось залив через «фото товару» величезні ліві файли, адже розмір і тип ніхто не перевіряв.
3. В адмінку зайшов сторонній - увесь захист тримався на «посилання не видно», а він просто вгадав адресу /admin.

Нічого з цього не сталося б, попроси ти агента подумати про безпеку із самого початку. І ось як це зробити одним промптом:

Зроби security-review мого проєкту перед публікацією. Перевір за чек-листом:

Секрети: чи немає паролів, API-ключів і токенів прямо в коді. Усе має бути в .env.local, а сам .env.local - у .gitignore.
Ввід користувача: чи перевіряється весь ввід. Для завантаження файлів обмеж розмір, тип і розширення за білим списком.
Права доступу: чи перед кожною важливою дією (видалення, зміна, чужі дані) є перевірка прав на сервері, а не лише схована кнопка.
Помилки й логи: чи показуються користувачу загальні повідомлення, чи не потрапляють у логи паролі й номери карток.
Покажи список знайдених проблем простими словами і запропонуй, як полагодити кожну.

Часті помилки новачка в безпеці

• «Я нікому не потрібен». Боти сканують усіх підряд автоматично. Розмір сайту тут узагалі ні до чого.
• Ключ у коді плюс публічний гіт. Класика жанру. Секрети - у .env.local, файл - у .gitignore.
• Захист «кнопку не видно». Сховати в інтерфейсі - не означає захистити. Перевірка прав живе на сервері.
• Форма приймає що завгодно. Перевіряй ввід і файли за білим списком, а не на «може, пронесе».
• Повний текст помилки в обличчя користувачу. Це мапа для зломщика. Йому - «упс», подробиці - в логи.
• Логувати паролі й картки. Витече лог - витече все. Секретам у логах не місце.
• Публікувати без ревʼю. Один промпт security-review ловить більшість дитячих дір і коштує нуль гривень.