Я провів аудит безпеки своїх сторонніх проєктів — ось що я знайшов

𝗜 𝗔𝘂𝗱𝗶𝘁𝗲𝗱 𝗠𝘆 𝗦𝗶𝗱𝗲 𝗣𝗿𝗼𝗷𝗲𝗰𝘁𝘀 𝗳𝗼𝗿 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 — 𝗛𝗲𝗿𝗲 𝗜𝘀 𝗪𝗵𝗮𝘁 𝗜 𝗙𝗼𝘂𝗻𝗱

Нещодавно я провів аудит усіх своїх сторонніх проєктів. Я перевірив свої бекенди на FastAPI, Telegram-ботів та вебзастосунки. Я думав, що я обережний.

Я помилявся.

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

Ось основні проблеми, які я виявив, та способи їх вирішення:

1. Умовна автентифікація Я писав код, який перевіряв API-ключі лише за наявності секретного ключа (secret). Якщо я забував встановити secret у своєму оточенні, перевірка повністю пропускалася. Це залишало мій API відкритим для всіх.

• Виправлення: Ніколи не робіть автентифікацію умовною. Якщо secret відсутній, застосунок має видати помилку та зупинитися.

2. Витік ключів в історії Git Я знайшов старі API-ключі в історії Git. Пізніше я переніс їх у файли .env, але Git зберігає кожну стару версію вашого коду назавжди.

• Виправлення: Вважайте будь-який ключ, який коли-небудь був закомічений в Git, скомпрометованим. Негайно відкличте його. Використовуйте такі інструменти, як git-filter-repo, щоб очистити історію.

3. Залишені ендпоінти для налагодження Я залишив у продакшні ендпоінти, які показували конфігурацію моєї бази даних та системні налаштування. Вони корисні під час розробки, але небезпечні в реальних умовах.

• Виправлення: Додайте видалення debug-ендпоінтів до вашого чекліста розгортання.

4. Занадто детальні повідомлення про помилки Я повертав користувачеві сирі системні помилки. Ці помилки розкривають шляхи до файлів, типи баз даних та версії бібліотек. Зловмисник може використати ці дані для атаки на вашу систему.

• Виправлення: Логуйте повну помилку внутрішньо для себе. Повертайте клієнту загальне повідомлення "Internal Server Error".

5. XSS через innerHTML Я використовував innerHTML для рендерингу даних користувача у своєму фронтенді. Це дозволяє зловмисникам впроваджувати скрипти на ваш сайт.

• Виправлення: Завжди санітізуйте дані або використовуйте textContent замість innerHTML.

6. Відсутність обмеження частоти запитів (Rate Limiting) У мене були ендпоінти, які викликали дорогі моделі ШІ без жодних обмежень. Один користувач міг за лічені хвилини нараховувати величезні рахунки.

• Виправлення: Автентифікація зупиняє неавторизованих користувачів. Rate limiting зупиняє авторизованих користувачів від зловживання вашою системою. Вам потрібні обидва механізми.

7. Занадто дозволяючи налаштування CORS Я використовував allow_origins=["*"] у своєму middleware. Це дозволяє будь-якому вебсайту робити запити до вашого API.

• Виправлення: У продакшні дозволяйте лише ваші конкретні домени.

8. Витік файлів Я писав код, який створював тимчасові файли, але не видаляв їх у разі збою процесу. Ці файли залишаються на вашому сервері назавжди.

• Виправлення: Використовуйте блок try-finally, щоб гарантувати видалення файлів навіть у разі виникнення помилки.

Проблеми з безпекою рідко є навмисними. Вони є результатом фрази «Я виправлю це пізніше». Але це «пізніше» ніколи не настає.

Впроваджуйте безпеку у свій робочий процес із першого дня. Перевіряйте свій код перед тим, як робити коміт і перед розгортанням.

Джерело: https://dev.to/justjinoit/i-audited-my-own-side-projects-for-security-issues-heres-what-i-found-1ahb