Как защитить сайт: практический минимум для малого бизнеса

Безопасность начинается с вопроса «что мы защищаем?»

Лендинг с контактной формой и сервис, который хранит аккаунты, документы и заказы, требуют разного уровня защиты. Но базовые правила одинаковы: минимизировать доступ, не хранить секреты публично, регулярно обновлять зависимости и заранее думать, что произойдёт при ошибке или компрометации.

1. Только HTTPS для публичного сайта

Формы входа, cookies и личные данные не должны передаваться открытым текстом. Настройте сертификат и перенаправление с HTTP на HTTPS. Для большинства современных платформ обновление сертификата можно автоматизировать.

2. Пароли: длинные, уникальные, а для админов — MFA

Главная опасность повторяющегося пароля в том, что утечка одного сервиса открывает дверь в другой. Для административных аккаунтов добавьте второй фактор, а для команды используйте менеджер паролей вместо общей таблицы «доступы.xlsx».

3. Секреты не должны попадать в frontend и Git

API-ключ базы, SMTP-пароль, секрет сессий и приватные токены хранятся в переменных окружения или secret manager. Всё, что отправлено в JavaScript браузера, нужно считать публичным: пользователь может открыть DevTools и прочитать код.

4. Проверяйте права на сервере, а не только скрывайте кнопку

Если кнопка «Удалить заказ» видна только администратору — это хорошо для интерфейса, но недостаточно для безопасности. Сервер должен отдельно проверить роль пользователя при каждом административном запросе. Иначе человек может вручную отправить запрос к API, даже не видя кнопку.

5. Загрузка файлов требует отдельного внимания

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

6. Формы: валидация, rate limit и защита от спама

Frontend-валидация нужна для удобства, но злоумышленник может её обойти. Поэтому сервер снова проверяет email, длину строк, обязательные поля и допустимые значения. Для входа, восстановления пароля и публичных форм полезно ограничивать частоту запросов.

7. Обновляйте систему

Устаревшая CMS, plugin или библиотека с известной уязвимостью — одна из самых понятных точек входа. Составьте простой ритуал: раз в определённый период проверять обновления, читать критические security notices и удалять зависимости, которые больше не используются.

8. Backup должен существовать до инцидента

Резервная копия нужна не только от взлома. Ошибка миграции, случайное удаление или неудачный deploy встречаются гораздо чаще. Убедитесь, что копируются база и пользовательские файлы, а восстановление хотя бы однажды проверено.

9. Логи помогают понять, что произошло

Сохраняйте ошибки сервера и важные административные действия. При этом не стоит писать в логи пароли, токены и полный набор чувствительных данных. Лог должен помогать расследовать событие, а не создавать новую утечку.

Минимальный чеклист перед запуском

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

10. Относитесь к сессии как к ключу от аккаунта

После входа пользователь обычно получает cookie или токен, который подтверждает его сессию. Для browser-сессий полезны безопасные настройки cookie, разумный срок жизни и возможность завершить сессию после смены пароля. Администраторская сессия может требовать более строгих правил, чем обычный публичный аккаунт.

11. Не собирайте данные «на всякий случай»

Чем меньше чувствительной информации хранит система, тем меньше последствия возможной утечки. Если для выполнения заказа не нужна дата рождения клиента — не просите её. Если загруженный файл можно удалить после завершения заказа — определите срок хранения вместо вечного архива.

Это полезно не только для безопасности: понятная политика данных упрощает поддержку и снижает количество старой информации, о которой никто уже не помнит.

12. Заранее решите, что делать при инциденте

Минимальный план может быть очень коротким: кто получает уведомление, как временно отключить опасную функцию, где поменять секреты, как отозвать сессии, откуда восстановить данные и какие логи сохранить для разбора. В момент проблемы намного легче идти по списку, чем впервые обсуждать процесс в чате.