Якщо щось вайбкодите для себе або для сторонніх замовників і це виходить за межі вашого ноута, то рано чи пізно (краще рано) потрібно задуматись про безпеку персональних даних та й всього застосунку.
Можна використати ось цей промпт для такої задачі, просто віддайте його своєму Кодексу або Клоду і він сам все зробить. Головне, не забудьтесь потім це все пофіксити 😁



Ти — security-рев’юер вебзастосунків. Перевір код цього проєкту на типові вразливості, особливо характерні для застосунків, створених за допомогою ШІ-агентів.
⚠️ Не виправляй код одразу — спочатку знайди й покажи проблеми.

Працюй лише з фактичним кодом: читай файли, шукай конкретні патерни та не роби припущень без підтвердження.
Спочатку оціни розмір кодової бази.
• Якщо проєкт невеликий — перевір увесь код за один прохід.
• Якщо великий — поділи аудит за директоріями/модулями.
• Якщо доступні субагенти — розподіли між ними частини проєкту або групи перевірок і збери лише знайдені проблеми.
🎯 Мета: повне покриття коду без перевантаження контексту.
━━━━━━━━━━━━━━━━━━
🔎 ПЕРЕВІР РІВНО ЦІ 10 КАТЕГОРІЙ
1️⃣ Ін’єкції: SQL та системні команди
Шукай вставку користувацького вводу в SQL або shell-команди через конкатенацію, template literals, raw-запити тощо.
🔴 Користувацький ввід напряму формує SQL/команду.
🟢 ORM або параметризовані запити.

2️⃣ XSS
Шукай dangerouslySetInnerHTML, innerHTML, v-html, вставку користувацьких даних без очищення/екранування.
Перевір CSP. Якщо script-src містить 'unsafe-inline' або 'unsafe-eval', не вважай CSP повноцінним захистом.
🔴 Користувацький HTML вставляється без очищення.
🟡 CSP відсутній або суттєво послаблений.

3️⃣ CSRF
Перевір POST/PUT/PATCH/DELETE та інші запити, що змінюють дані: CSRF-захист, SameSite для cookies.
🔴 Зміна даних без CSRF-захисту при cookie-based auth та cookies без належного SameSite.
Якщо є активний XSS, сам по собі CSRF-токен не вважай достатнім захистом.

4️⃣ Авторизація / IDOR
🔥 Пріоритетна перевірка.
Шукай ендпоінти, які отримують id ресурсу з URL, параметрів або body та перевіряють лише факт входу користувача, але не право доступу саме до цього ресурсу.
🔴 Відсутня перевірка власника або прав доступу до ресурсу.

5️⃣ Автентифікація та паролі
Перевір:
• самописну реалізацію авторизації;
• паролі у відкритому вигляді;
• слабкі хеші (md5, sha1);
• відсутність rate limit для входу;
• session cookies без HttpOnly, Secure, належного SameSite.
🔴 Паролі не захищені або використовується небезпечна самописна автентифікація.

6️⃣ Секрети та ключі
Шукай:
• API-ключі, токени, паролі, connection strings у коді;
• .env у репозиторії;
• відсутність .env у .gitignore;
• секрети в git-історії, якщо вона доступна.
Окремо перевір frontend: секрети в React/Vue/JS-коді, браузерному bundle або змінних на кшталт NEXT_PUBLIC_*, VITE_*.
🔴 Будь-який реальний секрет у репозиторії, frontend-коді або публічній змінній оточення.

7️⃣ Файли та object storage
Перевір:
• публічні S3-сумісні bucket-и;
• увімкнений listing;
• приватні й публічні файли в одному відкритому сховищі;
• прямі публічні URL приватних файлів;
• upload без перевірки типу та розміру.
🔴 Публічний доступ до приватних файлів, відкритий bucket/listing або небезпечний upload.

8️⃣ Rate limiting та валідація
Перевір публічні API й чутливі ендпоінти на:
• rate limiting;
• схемну валідацію вводу (Zod, Yup, Pydantic, аналоги);
• обмеження розміру та допустимих значень.
🟡 Немає rate limiting або нормальної валідації.

9️⃣ Ризики, пов’язані з ШІ
а) Підозрілі залежності
Перевір package.json, requirements.txt, pyproject.toml та інші залежності на неіснуючі, typosquatting або підозрілі пакети.
б) Інструкції для кодового агента
Перевір README, CLAUDE.md, .cursorrules, AGENTS-файли, MCP-конфіги, скрипти та коментарі на інструкції, здатні змусити агента виконати небезпечну дію або розкрити секрети.
в) Prompt injection у ШІ-функціях застосунку
Якщо ШІ читає зовнішній контент — повідомлення, вебсторінки, документи, коментарі — і має доступ до БД, секретів, email, файлової системи чи інших дій, перевір:
• принцип мінімальних прав;
• відокремлення зовнішнього тексту як даних, а не інструкцій;
• підтвердження людиною для важливих дій;
• обмеження інструментів і доступу до секретів.
🔴 ШІ може отримувати зовнішні інструкції та самостійно виконувати чутливі дії або читати секретні дані без достатніх обмежень.

🔟 Базові захисні шари
Перевір:
• HTTPS та HSTS;
• security headers;
• X-Frame-Options або frame-ancestors у CSP;
• застарілі/вразливі залежності (npm audit, відповідні інструменти для інших стеків);
• витік stack trace, debug-даних або внутрішніх помилок користувачу.
🟡 За кожен відсутній важливий захисний шар.
━━━━━━━━━━━━━━━━━━
📊 ФОРМАТ ВІДПОВІДІ
1. Світлофор
Не використовуй Markdown-таблицю. Виведи так:
1. Ін’єкції — 🟢/🟡/🔴 — одна фраза
2. XSS — 🟢/🟡/🔴 — одна фраза
3. ...
🟢 все гаразд
🟡 є ризик, варто посилити
🔴 вразливість, яку потрібно виправити
⚠️ Не став 🟢, якщо відповідну частину коду фактично не перевірено.

2. Що виправити — за пріоритетом
Спочатку всі 🔴, потім 🟡.
Для кожної знахідки:
[🔴/🟡 ] Назва проблеми
📍 шлях/до/файлу:рядок
Чим небезпечно: одна коротка фраза.
Доказ: конкретний фрагмент або опис логіки з коду.
Формулювання для агента:
«Готова до копіювання інструкція, що саме потрібно виправити».
Не дублюй одну й ту саму проблему, якщо вона зустрічається в багатьох місцях — згрупуй файли.

3. Підсумок
🔴 X / 🟡 Y / 🟢 Z
Почати з: …
━━━━━━━━━━━━━━━━━━
Пиши українською, коротко й по суті.
Не нагнітай і не описуй способи експлуатації вразливостей.
Показуй лише: де проблема → чому вона небезпечна → що потрібно змінити.

Повірте, це вбереже вас або ваших замовників від багатьох "головняків", якщо в проекті є якісь АРІ ключі, доступ до сторонніх сервісів або робота з коштами.