Чекліст безпеки для нового цифрового продукту
Відділ безпеки в перший день не потрібен. Потрібен короткий список, який ви не пропустите.
Спочатку ідентичність
Беріть перевірений auth або добре тестовану бібліотеку. Хешуйте паролі правильно. MFA для адмінів. Сесії з терміном. Не пишіть власну крипту. Якщо доступ скидається через пошту — цей флоу частина поверхні безпеки, не маркетингова дрібниця.
Більшість витоків — не голлівудський хак. Це забутий адмін, публічний бакет або секрет у репозиторії.
/ Dimitriy Caliber
Дані й секрети
Секрети — в оточенні або сховищі, ніколи в git. Бекапи є, і ви хоча б раз відновлювали. Файли клієнтів не на публічному URL. Якщо є health чи платіжні дані — знайте, які поля чутливі і хто їх бачить. Логи не повинні друкувати токени чи персональні дані в Slack.
- HTTPS скрізь, включно з адмінкою
- Ролі з мінімумом прав, не один бог-юзер
- Оновлення залежностей за календарем, не за настроєм
Поверхня продукту
Валідуйте на сервері. Лімітуйте логін і публічні форми. Ховайте детальні помилки від чужих. Завантаження файлів — з типом і розміром. Публічне API — з автентифікацією. Це не «ентерпрайз»-добавки. Так ви не станете заголовком з нудної причини.
Прохід на тижні запуску
Перед релізом: ротація ключів, хто ще має прод, бекапи, шлях видалення акаунта якщо збираєте персональні дані. Після релізу: тиждень дивіться логи автентифікації. Безпека — звичка поруч із поставкою, не PDF у шухляді.
Є проєкт на думці?
Залиште ім'я та зручний контакт. Ми повернемося з наступним кроком.