Этапы проверки качества работы
Это описание идеального проекта. Некоторые пункты могут быть пропущены в зависимости от проекта.
- Дизайн-макет передан заказчику
- Владение Git-репозиторием передано заказчику
- Документация к проекту существует
- Настроены резервные копии (backup) сайта и базы данных
- Успешно пройдены тесты в Google Lighthouse
- SEO подготовка страниц - теги, файлы, schema.org
- Произведено несколько автотестов перед публикацией проекта
- Существует мониторинг производительности и ошибок
- Установлен SSL-сертификат
- Домен и хостинг принадлежат заказчику
- Сайт подключен к Яндекс.Вебмастер, к Google Search Console
Продвинутые проблемы безопасности
OWASP Top 10 — это международный стандарт безопасности, который описывает самые критические риски для современных веб-приложений. Это не просто список багов, а перечень системных ошибок в архитектуре и разработке, которые чаще всего приводят к взломам.
1. Broken Access Control (Нарушение контроля доступа). Самая частая проблема, при которой пользователь получает доступ к данным или функциям за пределами своих полномочий. Например, когда злоумышленник может просматривать чужие заказы, просто меняя ID в адресной строке браузера.
2. Cryptographic Failures (Ошибки криптографии). Сюда относится передача данных по незащищенным протоколам (HTTP), хранение паролей в открытом виде или использование устаревших алгоритмов шифрования. Это прямой путь к утечке конфиденциальной информации и персональных данных пользователей.
3. Injection (Инъекции). Классическая угроза, при которой вредоносный код (SQL, NoSQL или команды ОС) вставляется в поля ввода и исполняется сервером. Это позволяет хакерам выкачивать базы данных или выполнять произвольные команды на вашем сервере.
4. Insecure Design (Небезопасное проектирование). Ошибки, допущенные еще на этапе планирования архитектуры. Если логика восстановления пароля или проведения платежей изначально содержит изъяны, то даже идеально написанный код не сможет обеспечить должную защиту.
5. Security Misconfiguration (Неправильная настройка). В этот пункт входит публикация Source Maps в продакшене, использование стандартных паролей для админок, открытые лишние порты и вывод подробных сообщений об ошибках со stack trace, которые помогают атакующему изучить систему.
6. Vulnerable and Outdated Components (Уязвимые компоненты). Использование сторонних библиотек и фреймворков с известными дырами. Помните, что ваш проект состоит из зависимостей на 80–90%, и уязвимость в маленьком npm-пакете может скомпрометировать всё приложение.
7. Identification and Authentication Failures (Ошибки идентификации). Сюда относятся слабые требования к паролям, отсутствие защиты от перебора (брутфорса), отсутствие двухфакторной аутентификации и неправильная работа с сессиями пользователей, позволяющая угнать чужой аккаунт.
8. Software and Data Integrity Failures (Нарушение целостности). Риски, связанные с автоматическими обновлениями ПО без проверки подписи или десериализацией данных из ненадежных источников. Если приложение слепо доверяет входящему объекту, оно может быть взломано изнутри.
9. Security Logging and Monitoring Failures (Ошибки логирования). Если система не фиксирует подозрительную активность, взлом может оставаться незамеченным месяцами. Без качественных логов невозможно провести расследование инцидента и вовремя остановить атаку.
10. Server-Side Request Forgery (SSRF). Атака, при которой сервер заставляют отправить запрос на внутренние ресурсы компании (базы данных, облачные метаданные), которые обычно скрыты от внешнего мира сетевыми экранами.
Понимание этих десяти пунктов помогает разработчикам создавать защищенные продукты с самого начала, а не «затыкать дыры» уже после того, как данные утекли в сеть.
Клиентские секреты в коде (Secrets Leakage). Это логическое продолжение проблемы с Source Maps. Разработчики часто оставляют API-ключи (Firebase, Stripe, AWS) прямо в коде. Даже без Source Maps их можно вытащить из минифицированного JS обычным поиском по строкам. Решение: использовать переменные окружения и проксировать запросы к критичным API через свой бэкенд.
Clickjacking (Угон клика). Это когда твой сайт вставляют в невидимый iframe на другом вредоносном ресурсе. Пользователь думает, что нажимает на кнопку «Выиграть приз» на чужом сайте, а на самом деле нажимает на кнопку «Удалить аккаунт» на твоем, так как он там авторизован. Решение: заголовок X-Frame-Options: DENY или правильная настройка Content Security Policy (CSP).
Открытые редиректы (Unvalidated Redirects). Если у тебя есть параметр в URL типа ?returnUrl=/dashboard, хакер может подставить туда ?returnUrl=http://fake-login-page.com. Пользователь увидит знакомый домен в начале ссылки, перейдет по ней, совершит действие и будет перенаправлен на фишинговый сайт. Решение: разрешать редиректы только на относительные пути или по белому списку доменов.
CORS Misconfiguration (Ошибки CORS). Самая частая ошибка — настройка Access-Control-Allow-Origin: * вместе с Allow-Credentials: true. Это позволяет любому вредоносному сайту в браузере пользователя делать запросы к твоему API от имени этого пользователя (с его куками). Решение: никогда не использовать «звездочку» для авторизованных зон, только конкретные доверенные домены.
Prototype Pollution (Загрязнение прототипа). Специфическая уязвимость JavaScript. Если ты используешь функции глубокого слияния объектов (merge/extend) без проверки ключей, хакер может передать ключ proto. Это изменит поведение всех объектов в приложении и может привести к выполнению произвольного кода. Решение: использовать Object.create(null) для словарей или современные библиотеки с защитой от этой атаки.
Чувствительные данные в URL. Иногда разработчики передают токены подтверждения почты, сессии или личные данные (email) прямо в GET-параметрах. Эти данные навсегда остаются в истории браузера, в логах прокси-серверов и передаются в заголовке Referer на сторонние ресурсы (например, метрикам). Решение: передавать чувствительную информацию только в теле POST-запросов или в заголовках.
Брутфорс перечисление (Resource Enumeration). Если при вводе логина сайт пишет «Пользователь не найден», а при вводе правильного — «Неверный пароль», ты выдаешь хакеру список существующих логинов. Это же касается ID заказов или профилей. Решение: возвращать одинаковую общую ошибку «Неверный логин или пароль».