Я провел аудит безопасности своих пет-проектов — вот что я обнаружил

Я провел аудит своих сторонних проектов на предмет безопасности — вот что я обнаружил

Недавно я провел аудит всех своих сторонних проектов. Я проверил свои бэкенды на FastAPI, Telegram-ботов и веб-приложения. Я думал, что я осторожен.

Я ошибался.

Я нашел реальные баги, которые фактически попали в продакшн. Это не теоретические проблемы. Это ошибки, которые я совершил, пытаясь работать быстро.

Вот основные проблемы, которые я обнаружил, и способы их решения:

1. Условная аутентификация Я писал код, который проверял API-ключи только в том случае, если существовал секретный ключ (secret). Если я забывал установить секрет в переменных окружения, проверка просто пропускалась. Это оставляло мой API открытым для всех.

• Исправление: Никогда не делайте аутентификацию условной. Если секрет отсутствует, приложение должно выдавать ошибку и останавливаться.

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

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

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

• Исправление: Добавьте удаление отладочных эндпоинтов в ваш чек-лист развертывания.

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