Безопасность админ-панели: что проверить до запуска продукта

Практический чек-лист для CTO, Tech Lead и AppSec-специалиста — от контроля доступа до секретов в конфиге

Почему это важно именно сейчас

В январе 2026 года OWASP выпустил финальную версию обновлённого Top 10:2025 — первую с 2021 года. Список появился по итогам анализа более 175 000 CVE-записей и опроса специалистов по всему миру [1]. Два крупных изменения напрямую касаются тех, кто готовит продукт к запуску: Security Misconfiguration поднялась с 5-го на 2-е место, а Software Supply Chain Failures вошла в список как новая категория [1, 2].

Admin-панель — это самый ценный и при этом часто наименее защищённый компонент продукта. Если основной пользовательский интерфейс обычно проходит ревью, тестирование и security review, то внутренний операционный инструмент нередко разрабатывается в спринте «как-нибудь», выкатывается с дефолтными настройками и живёт под минимальным надзором.

CISA фиксировала в своём каталоге Known Exploited Vulnerabilities реальные атаки через открытые admin-интерфейсы: уязвимость Adobe ColdFusion (CVE-2024-20767) позволяла атакующему получить доступ к файлам и управлять системой именно через интернет-доступную admin-панель [3]. В 2025 году исследователи и команда Action1 зафиксировали паттерн: атакующие целенаправленно ищут management interfaces, не защищённые ACL или VPN [4]. «Слой управления» стал отдельным вектором атаки.

Цена ошибки — высокая. По данным за 2025 год, средняя стоимость одного инцидента безопасности составляет 4,45 млн долларов, при этом среднее время обнаружения — 287 дней [5].

Раздел 1. Контроль доступа: аутентификация и авторизация

Почему это первое и главное

Broken Access Control стал категорией №1 в OWASP Top 10 ещё в 2021 году и сохранил позицию в 2025: нарушения контроля доступа обнаруживаются примерно в 94% протестированных приложений [6]. Для admin-панели это означает не просто утечку данных одного пользователя — это полный контроль над продуктом.

Аутентификация: минимальная планка

Обязательный минимум перед запуском:

1. MFA включён для всех администраторских учёток без исключений. Исследования Microsoft показывают, что MFA блокирует более 99,2% атак на компрометацию учётных записей [7]. Начиная с октября 2024 года сам Microsoft ввёл обязательный MFA для всех административных интерфейсов Azure и Microsoft Entra [7]. Аппаратные ключи (FIDO2/passkey) или TOTP-приложения — сильнее, чем SMS.
2. Нет дефолтных паролей. После установки или первого деплоя убедитесь, что ни одна учётная запись не имеет пароля из поставки (admin/admin, root/root, и любые vendor defaults). Перед запуском пройдитесь по всем сервисам: база данных, очереди, административные интерфейсы инфраструктуры.
3. Политика паролей применяется на сервере, а не только в UI-валидации. Минимальная длина, запрет повторного использования последних N паролей, ограничение на подбор.
4. Session management: сессии с коротким TTL для admin-интерфейса (30–60 минут idle timeout), явный logout, инвалидация сессии при смене пароля.

Авторизация: RBAC и принцип минимальных привилегий

Модель авторизации на основе ролей (RBAC) — не просто удобная организация доступа, это механизм контроля «взрывного радиуса». Если учётная запись support-оператора компрометирована, она не должна давать доступ к финансовым данным или возможности удалять пользователей [8].

Что проверять:

1. Роли определены явно: каждая роль имеет задокументированный список разрешений. Нет «суперпользователей» для удобства, если под ними работают несколько человек.
2. Авторизация проверяется на сервере при каждом запросе, а не только на уровне UI. Разграничение через скрытые кнопки или CSS — не контроль доступа.
3. Нет IDOR (Insecure Direct Object Reference): каждый запрос на объект проверяет принадлежность этого объекта текущему пользователю, а не только факт аутентификации. IDOR — самый распространённый тип broken access control в 2026 году [9].
4. Нет вертикальной эскалации привилегий: обычный пользователь не должен иметь возможности получить admin-доступ через манипуляцию параметрами запроса, JWT-токеном или session cookie. Проверьте все эндпоинты admin-зоны на прямой доступ без авторизации (force browsing).
5. Регулярный ревью прав: «privilege creep» — накопление избыточных прав со временем — системная проблема [10]. Перед запуском убедитесь, что у dev-аккаунтов и staging-доступов нет прав в production.

Для деструктивных операций (массовое удаление, экспорт всей базы, изменение роли другого admin) рекомендуется дополнительная ступень аутентификации или approval workflow [8].

Раздел 2. Сетевая изоляция: кто вообще может попасть на эту страницу

Admin-панель не должна быть видна из интернета

Одна из самых частых конфигурационных ошибок при запуске — admin-интерфейс, доступный по публичному IP без дополнительного ограничения. Атакующие целенаправленно ищут такие интерфейсы через Shodan и аналогичные инструменты. В 2025 году именно открытые management interfaces стали приоритетной точкой входа [4].

Варианты ограничения в порядке возрастания надёжности:

1. IP whitelist: только явно перечисленные адреса могут достучаться до /admin или его аналога. Эффективен для команд с фиксированными офисными IP. Уязвим к компрометации устройства из whitelist-сети, поэтому должен быть слоем, а не единственным контролем [11].
2. VPN или Zero Trust Network Access (ZTNA): admin-интерфейс недоступен без подключённого VPN. Рекомендуется для распределённых команд. Российский контекст: корпоративные VPN-шлюзы от отечественных вендоров (S-Terra, Infotecs ViPNet и другие) поддерживают аналогичные сценарии.
3. Identity-Aware Proxy (IAP): доступ проверяется не только по сети, но и по идентификатору пользователя и устройства. Cloudflare Access, BeyondCorp, Yandex Cloud Access Policy — примеры реализации.
4. Смена стандартного пути: URL /admin, /wp-admin, /administrator — первые кандидаты для автоматических сканеров. Нестандартный путь — не защита сам по себе, но снижает шум от автоматических атак.

Защита от перебора

Rate limiting на эндпоинтах аутентификации — обязателен. Конкретные рекомендации:

1. Ограничение по количеству попыток на IP и на аккаунт в заданном временном окне.
2. Progressive delay или временная блокировка после N неудачных попыток (с уведомлением владельцу аккаунта).
3. Осторожность с X-Forwarded-For: если rate limiting опирается только на этот заголовок, его можно подделать [12].
4. Monitoring: оповещение на аномальное число failed login attempts — это ранний сигнал атаки.

Раздел 3. Секреты и конфигурация: самое опасное в .env

Почему секреты в конфиге — критический риск

Один открытый .env файл или незащищённый .git-репозиторий даёт атакующему полный доступ к базе данных, сторонним API и облачной инфраструктуре [13]. Это не теоретический риск: взлом Internet Archive в октябре 2024 года, затронувший более 31 миллиона аккаунтов, был в том числе связан с открытым GitLab configuration file [14].

Перед запуском проверить:

1. .env, .env.production, .env.local — не попадают в репозиторий и не доступны по HTTP. Убедитесь через .gitignore и ручную проверку .git/config доступности снаружи.
2. Debug mode отключён: APP_DEBUG=false, WP_DEBUG=false, аналоги в вашем стеке. Режим отладки в production раскрывает стек вызовов, переменные окружения и пути к файлам [13].
3. Нет хардкода credentials в коде: пароли, токены, API-ключи не лежат в исходниках. Используйте сканеры секретов (truffleHog, detect-secrets, Semgrep) в pre-commit hook и в CI.
4. Production-specific credentials: база данных в production использует отдельные учётные данные, не те же, что staging или dev [13].
5. Секреты ротируются: при смене сотрудника или при любом подозрении на компрометацию — ротация всех секретов, к которым имел доступ. Автоматизированная ротация через HashiCorp Vault, AWS Secrets Manager или аналоги — лучшая практика [15].

По рекомендациям OWASP Secrets Management Cheat Sheet, минимум аудита секретов включает: кто и когда запрашивал секрет, был ли запрос авторизован, когда секрет использовался и кем, истёк ли он, есть ли попытки использовать истёкшие секреты [15].

Security Misconfiguration: второе место в OWASP 2025

Security Misconfiguration поднялась с 5-го на 2-е место в обновлённом OWASP Top 10:2025, отражая реальность: сложность инфраструктуры растёт, и ошибки конфигурации стали системной проблемой [2]. Что проверить помимо секретов:

1. Нет открытых портов, которые не должны быть открыты. База данных, Redis, RabbitMQ — не должны быть доступны напрямую из интернета. Проверьте через nmap или облачный security group audit.
2. CORS настроен строго: Access-Control-Allow-Origin: * в admin-интерфейсе — ошибка. Разрешайте только доверенные origins [13].
3. Directory listing отключён на веб-сервере.
4. Backup-файлы (.bak, .old, .zip) и конфигурационные файлы недоступны через HTTP.
5. Версии ПО не раскрываются в заголовках (Server, X-Powered-By) — это не защита, но снижает ценность автоматического fingerprinting.

Раздел 4. HTTP Security Headers: дешевле, чем кажется

Согласно сканированию топ-1 млн сайтов в 2025 году, менее 25% развернули осмысленный Content Security Policy, и почти 40% не имели даже базовых заголовков вроде X-Content-Type-Options [16]. Это огромная «дыра», которая закрывается несколькими строками конфигурации nginx или Apache.

Минимальный набор для admin-панели:

1. Content-Security-Policy (CSP) — ограничивает, откуда браузер может загружать скрипты, стили, изображения. Защищает от XSS даже при наличии уязвимости в коде. Рекомендуется развернуть в режиме Report-Only сначала, наблюдать за нарушениями, затем включить enforcement [17].
2. Strict-Transport-Security (HSTS) с max-age=31536000 — принудительный HTTPS, защита от SSL-stripping атак.
3. X-Frame-Options: DENY или SAMEORIGIN — защита от clickjacking. Современная альтернатива — frame-ancestors 'none' в CSP [18].
4. X-Content-Type-Options: nosniff — запрещает браузеру интерпретировать файлы в типах, отличных от заявленных (защита от MIME confusion).
5. Referrer-Policy: strict-origin-when-cross-origin — контроль над передачей referrer к внешним ресурсам.
6. Permissions-Policy — ограничение доступа к браузерным API (камера, микрофон, геолокация).

Для admin-панели имеет смысл применять более строгую CSP, чем для публичного фронтенда, так как набор разрешённых ресурсов там узкий и предсказуемый.

Проверить результат можно через securityheaders.com или Mozilla Observatory — бесплатные публичные инструменты.

Раздел 5. Аудит-лог: что произошло и кто это сделал

Зачем это нужно до запуска, а не после инцидента

Аудит-лог — это не только forensics-инструмент. Это механизм раннего обнаружения: аномальное число операций от одного пользователя, доступ к данным в нерабочее время, эскалация привилегий — всё это видно в логах до того, как ущерб стал необратимым.

Регуляторы и стандарты (SOC 2, PCI DSS, HIPAA, ФЗ-152 в российском контексте) требуют детальных аудит-логов с достаточным периодом хранения. Настраивать это уже после запуска — значит работать без инструмента в самый уязвимый период.

Что логировать

По рекомендациям OWASP Secrets Management и best practices индустрии [15, 19]:

1. Все попытки аутентификации: успешные и неуспешные входы с IP, timestamp, user-agent.
2. Все административные действия: кто, что, когда изменил. Для объектов — «before/after» diff там, где это возможно.
3. Смена ролей и прав: кто кому назначил роль и с каким основанием.
4. Экспорт данных: любой bulk export требует отдельной записи в лог.
5. Попытки доступа к запрещённым ресурсам (403-ответы от авторизованного пользователя — признак разведки).
6. Административные действия с инфраструктурой: изменения конфигурации, перезапуски сервисов.

Чего не логировать

Аудит-лог сам может стать источником утечки. Никогда не логируйте в явном виде: пароли, токены, API-ключи, номера карт, SSN и другие чувствительные данные. Применяйте data minimisation: фиксируйте факт и контекст операции, а не её содержимое [19].

Integrity и хранение

Логи должны быть защищены от модификации. Минимально: отдельное хранилище с append-only доступом, ротация с шифрованием. Идеально: централизованный SIEM с отдельной политикой доступа. Если атакующий получил admin-доступ и удалил логи — это отдельная задача для incident response. Если логи нельзя удалить — это сильно осложняет сокрытие следов [10].

Раздел 6. Зависимости и supply chain: что приехало в вашем коде

Новый приоритет: Software Supply Chain Failures

В OWASP Top 10:2025 появилась новая категория — A03: Software Supply Chain Failures. Она расширяет прежнюю «Vulnerable and Outdated Components» до всего цикла разработки: зависимости, build system, инфраструктура дистрибуции [2]. У этой категории наименьшее число задокументированных случаев в тестовых данных — но наивысший средний балл по exploit и impact из CVE-базы [1].

Для admin-панели это означает: библиотека с известной уязвимостью в вашей backend-зависимости может дать атакующему полный доступ, даже если вся бизнес-логика написана корректно.

Что проверить перед запуском:

1. npm audit / pip audit / composer audit — запустить и убедиться, что нет critical и high уязвимостей без обоснованного исключения.
2. Lock-файлы зафиксированы в репозитории (package-lock.json, poetry.lock, Pipfile.lock): это гарантия воспроизводимой сборки и защита от тихой подмены зависимости.
3. Нет «package hallucinations»: если в проекте есть зависимости, добавленные через AI-ассистент, убедитесь, что они реальны и опубликованы официально — атакующие публикуют пакеты с именами, которые AI «придумывает».
4. Транзитивные зависимости: прямые deps — это только верхушка. Snyk, Dependabot, OWASP Dependency-Check помогают увидеть дерево целиком.

Раздел 7. Ключевые ошибки и как их избежать

Ошибка 1: «Admin-панель внутренняя, её не ломают»

Реальность: при компрометации любого устройства в корпоративной сети, при фишинге сотрудника или при утечке VPN-credentials — admin-интерфейс становится первой целью. «Внутреннее» не означает «безопасное».

Ошибка 2: Авторизация только на уровне UI

Скрытые кнопки, disabled-поля и отсутствующие ссылки — не контроль доступа. Атакующий работает с HTTP-запросами, а не с интерфейсом. Каждый эндпоинт проверяет права самостоятельно, независимо от того, «видна» ли кнопка в браузере [6].

Ошибка 3: MFA только для «обычных» пользователей

Admin-аккаунты — самая ценная цель. MFA обязателен именно для них в первую очередь. Исключения «для удобства» на аккаунтах с максимальными правами — критическая уязвимость.

Ошибка 4: Одни и те же credentials в dev, staging и production

Компрометация dev-окружения (которое обычно защищено слабее) не должна давать доступ к production. Отдельные секреты, отдельные ключи, отдельные service accounts — правило без исключений [13].

Ошибка 5: «Запустим, потом настроим мониторинг»

Самый уязвимый период — первые недели после запуска, когда сканеры и атакующие уже обнаружили ресурс, а команда ещё не выстроила операционные процессы. Мониторинг, алерты и аудит-лог должны работать с первого дня.

Ошибка 6: Не проверять, что уже задеплоено

Security misconfiguration часто возникает не в коде, а в конфигурации окружения. Автоматический внешний скан (OWASP ZAP, Nuclei, nmap) перед финальным запуском занимает от 30 минут и выявляет открытые порты, незащищённые эндпоинты, проблемы с TLS и заголовками [13].

Раздел 8. Практический чек-лист: gate перед запуском

Аутентификация и авторизация

• MFA включён для всех admin-аккаунтов
• Нет дефолтных паролей ни в одном сервисе
• Авторизация проверяется на сервере для каждого запроса
• Нет IDOR: ownership check на каждом защищённом ресурсе
• Нет vertical privilege escalation через манипуляцию параметрами
• Session timeout настроен и работает
• Dev/staging аккаунты не имеют прав в production

Сетевая защита

• Admin-интерфейс недоступен из открытого интернета (VPN / IP whitelist / IAP)
• Нет дефолтного пути /admin без дополнительного ограничения
• Rate limiting на эндпоинтах аутентификации
• Открытые порты только необходимые, база данных не торчит наружу
• CORS настроен без *

Конфигурация и секреты

• Debug mode отключён
• .env и конфигурационные файлы не в репозитории и не доступны по HTTP
• .git не доступен по HTTP
• Нет хардкода credentials в коде (проверить автоматически)
• Production credentials отличаются от dev/staging
• Backup-файлы недоступны через HTTP

HTTP Security Headers

• HSTS с min max-age=31536000
• CSP задан и не разрешает unsafe-inline без нужды
• X-Frame-Options: DENY или frame-ancestors 'none' в CSP
• X-Content-Type-Options: nosniff
• Referrer-Policy настроен

Аудит-лог

• Логируются все попытки аутентификации
• Логируются все admin-действия с атрибуцией (кто, что, когда)
• Логи защищены от удаления
• Алерты настроены: failed logins, privilege changes, bulk exports
• PII и секреты не попадают в логи в открытом виде

Зависимости

• npm audit / pip audit показывает 0 critical findings
• Lock-файлы зафиксированы
• Нет known-уязвимых версий библиотек без обоснованного исключения

Финальный внешний скан

• Автоматический скан завершён без critical findings
• All High findings: исправлены или задокументированы с owner и risk acceptance
• SSL/TLS действителен, auto-renewal настроен

Раздел 9. Инструменты и подходы для проверки

Автоматическая проверка не заменяет ревью, но снижает цену входа:

1. OWASP ZAP и Burp Suite Community — динамическое тестирование (DAST), проверка аутентификационных flows, поиск IDOR и broken access control [20].
2. Nikto — анализ конфигурации веб-сервера: открытые директории, опасные файлы, проблемы с заголовками.
3. nmap — инвентаризация открытых портов.
4. Nuclei (ProjectDiscovery) — шаблонный сканер, большая библиотека проверок, включая конфигурационные ошибки и CVE.
5. truffleHog / detect-secrets — поиск секретов в репозитории и истории коммитов.
6. Snyk / Dependabot / OWASP Dependency-Check — анализ уязвимостей в зависимостях.
7. securityheaders.com / Mozilla Observatory — проверка HTTP-заголовков.
8. Российский рынок: Metascan (включён в реестр российского ПО Минцифры) предоставляет SAST с ручной верификацией и отчётами в формате OWASP/CWE [21].

Инструменты покрывают автоматически обнаруживаемое. Ручной penetration test нужен для бизнес-логики: именно там живут нестандартные IDOR, privilege escalation через многошаговые workflows и логические ошибки в авторизации.

Раздел 10. AI-кодинг и admin-панели: отдельный разговор

Значительная часть internal tools, dashboard'ов и admin-интерфейсов сегодня пишется с помощью AI-ассистентов. Это ускоряет разработку, но создаёт специфические риски для безопасности:

Во-первых, AI-сгенерированный код часто содержит шаблонные авторизационные проверки, которые не адаптированы к реальной модели ролей продукта. Разработчик принимает pull request, который «работает», но не проверяет ownership на каждом эндпоинте.

Во-вторых, зависимости, предложенные AI, могут включать несуществующие пакеты (package hallucination). Перед merge такие зависимости требуют ручной проверки в реестре.

В-третьих, конфигурационные файлы и миграции — именно тот код, который читают хуже всего при ревью. AI может добавить отладочную переменную, широкий CORS или fallback-ключ в конфиг, и это уйдёт в production незамеченным.

Здесь уместен дополнительный слой контроля до merge и release. HighVibe анализирует конкретное изменение — код, конфигурацию, зависимости — в контексте релиза и даёт короткий понятный сигнал: что именно в этом PR требует внимания с точки зрения безопасности. Не длинный отчёт по всему репозиторию, а ответ на вопрос «можно ли безопасно принять это изменение сейчас». Для internal tools и admin-кода, где ревью часто поверхностное, это практически применимый контроль. Подробнее — на highvibe.dev.

Заключение: что делать прямо сейчас

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

Если до запуска осталось время, приоритеты следующие:

1. Проверьте, доступна ли admin-панель из открытого интернета. Если да — исправьте первым.
2. Убедитесь, что MFA работает для всех admin-аккаунтов.
3. Запустите автоматический внешний скан и закройте critical findings.
4. Проверьте .env и конфигурацию: нет ли секретов в открытом доступе.
5. Настройте аудит-лог и алерты до деплоя в production, а не после первого инцидента.

OWASP Top 10:2025 зафиксировал: нарушения контроля доступа и ошибки конфигурации — это не экзотика, это норма. Разрыв между тем, что доступно, и тем, что реально применяется, остаётся огромным. Цена закрытия этого разрыва — несколько дней работы. Цена его игнорирования — значительно выше.

Источники

[1] GitLab Blog — "OWASP Top 10 2025: What's changed and why it matters" — https://about.gitlab.com/blog/2025-owasp-top-10-whats-changed-and-why-it-matters/

[2] Fastly Blog — "The New 2025 OWASP Top 10 List: What Changed, and What You Need to Know" — https://www.fastly.com/blog/new-2025-owasp-top-10-list-what-changed-what-you-need-to-know

[3] CISA Known Exploited Vulnerabilities Catalog — CVE-2024-20767 (Adobe ColdFusion Admin Panel) — https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-20767

[4] Action1 Blog — "Top 10 Cybersecurity Vulnerabilities in 2025 and Why They Still Matter" — https://www.action1.com/blog/top-10-cybersecurity-vulnerabilities-in-2025-and-why-they-still-matter/

[5] aTeam Soft Solutions — "Web Application Security Checklist 2025: Complete OWASP Top 10 Implementation Guide for CTOs" — https://www.ateamsoftsolutions.com/web-application-security-checklist-2025-complete-owasp-top-10-implementation-guide-for-ctos/

[6] AquilaX Blog — "Broken Access Control and IDOR Explained — The #1 OWASP Vulnerability" — https://aquilax.ai/blog/broken-access-control-idor-explained

[7] Microsoft Learn — "Plan for mandatory Microsoft Entra multifactor authentication (MFA)" — https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication

[8] OSO HQ — "10 RBAC Best Practices You Should Know in 2025" — https://www.osohq.com/learn/rbac-best-practices

[9] SecureCodingHub — "Broken Access Control (OWASP A01): Examples & Fixes" — https://www.securecodinghub.com/blog/broken-access-control-owasp-explained

[10] ToolJet Blog — "How to Build Secure Internal Dashboards for Enterprises (RBAC, Audit Logs, Compliance)" — https://blog.tooljet.com/build-secure-internal-dashboards-for-enterprises/

[11] IPLocation.net — "Why IP Whitelisting Still Matters in 2025" — https://www.iplocation.net/why-ip-whitelisting-still-matters-in-2025

[12] Medium / Ahmad Sopyan — "Authentication part-6: Broken brute-force protection, IP block" — https://medium.com/@AhmadSopyan/authentication-part-6-broken-brute-force-protection-ip-block-ecbb6f63779f

[13] AI QA Monkey — "Pre-Launch Security Checklist: What to Verify Before Going Live" — https://aiqamonkey.com/blog/pre-launch-security-checklist.php

[14] Hornetsecurity Blog — "Major Cybersecurity Incidents of 2025 and Lessons Learned" — https://www.hornetsecurity.com/en/blog/cybersecurity-incidents/

[15] OWASP Cheat Sheet Series — "Secrets Management Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

[16] GF.dev — "The Complete Guide to HTTP Security Headers (2026)" — https://gf.dev/learn/web-security-headers

[17] DCHost Blog — "HTTP Security Headers Guide: How To Correctly Set HSTS, CSP, X-Frame-Options And Referrer-Policy" — https://www.dchost.com/blog/en/http-security-headers-guide-how-to-correctly-set-hsts-csp-x-frame-options-and-referrer-policy/

[18] DCHost Blog — "The Friendly Guide To HTTP Security Headers" — https://www.dchost.com/blog/en/the-friendly-guide-to-http-security-headers-how-i-set-up-hsts-csp-x-frame-options-and-x-content-type-options-without-breaking-stuff/

[19] SonarSource — "Audit Logging Best Practices, Components & Challenges" — https://www.sonarsource.com/resources/library/audit-logging/

[20] Workspace.ru — "Как провести аудит безопасности сайта перед запуском" — https://workspace.ru/blog/kak-provesti-audit-bezopasnosti-sayta-pered-zapuskom/

[21] Tproger — "Сервисы для тестирования безопасности веб-приложений" — https://tproger.ru/articles/servisy-dlya-testirovaniya-bezopasnosti-veb-prilozhenij