7 главных вопросов о веб-безопасности, которые задают чаще всего

Введение: почему веб-безопасность важна для каждого разработчика?

Каждый разработчик в своей практике хотя бы раз сталкивался со странными ошибками, непонятными блокировками или уязвимостями. Чаще всего из-за ошибки CORS перестает работать API, возникают сомнения при выборе системы аутентификации или разгораются споры о том, какой метод защиты пользовательских данных является правильным. Веб-безопасность актуальна не только для крупных корпораций, но и в равной степени для небольших Telegram-ботов, личных блогов и проектов электронной коммерции.

В этой статье мы собрали практические, понятные и проверенные опытом ответы на 7 самых частых вопросов о веб-безопасности, которые возникают у разработчиков.

1. Почему возникает ошибка CORS и как ее правильно исправить?

Ошибка CORS (Cross-Origin Resource Sharing) — первая и главная «головная боль» начинающих фронтенд- и бэкенд-разработчиков. Многие считают это ошибкой сервера, однако на самом деле CORS — это механизм безопасности, встроенный в браузер для защиты пользователя.

Когда ваше фронтенд-приложение (например, http://localhost:3000) отправляет запрос к бэкенд-API по совершенно другому адресу (например, http://api.pycoder.uz), браузер из соображений безопасности проверяет у бэкенда, разрешен ли доступ с этого адреса. Если бэкенд не возвращает необходимый заголовок Access-Control-Allow-Origin, браузер блокирует ответ.

Неправильное решение — вслепую отдавать Access-Control-Allow-Origin: * для всех запросов. Правильное решение — явно указать только доверенные домены фронтенда в настройках бэкенда:

# Django loyihasida django-cors-headers sozlamasi
CORS_ALLOWED_ORIGINS = [
    'https://pycoder.uz',
    'https://admin.pycoder.uz',
]

2. JWT-токен или сессии: что безопаснее и когда что использовать?

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

• Аутентификация на основе сессий: данные хранятся в памяти сервера или в базе данных, например Redis, а в браузер передается только секретный session_id через cookie. Если необходимо немедленно отозвать (revoke) сессию пользователя, сделать это очень просто. Это самый безопасный и удобный выбор для монолитных веб-сайтов и классических приложений на Django.
• JWT (JSON Web Token): сервер работает без сохранения состояния (stateless), то есть не хранит сессию в базе данных. Сам токен не зашифрован, а лишь подписан цифровой подписью. Это удобно для мобильных приложений, микросервисов и SPA (React/Vue). Однако главный недостаток JWT — сложность его досрочного отзыва.

Лучшая практика безопасности: рекомендуется хранить токены JWT не в localStorage браузера, а в cookie с установленными флагами HttpOnly и Secure. Это предотвращает кражу токенов.

3. Что такое XSS-атака (Cross-Site Scripting) и как от нее защититься?

При XSS-атаке злоумышленник внедряет сторонний код JavaScript на страницу сайта. Если сайт выводит введенные пользователем данные на экран напрямую без какой-либо фильтрации, вредоносный скрипт может выполниться в браузере других пользователей и украсть их cookie или токены.

Современные фреймворки, такие как React или Vue, автоматически экранируют переменные (escaping), то есть выводят теги <script> как обычный текст. Однако следует строго избегать следующих ситуаций:

• Использование свойства dangerouslySetInnerHTML в приложениях React для непроверенного текста.
• Пренебрежение очисткой входящих данных (HTML sanitization) на бэкенде — очистку нужно делать всегда.
• Отсутствие заголовка Content Security Policy (CSP): настроив его, вы запретите загрузку сторонних вредоносных скриптов на сайте.

4. Почему важна защита от CSRF-атак?

CSRF (Cross-Site Request Forgery) — это атака, при которой от имени пользователя без его ведома отправляется запрос на веб-сайт, где он уже аутентифицирован. Например, вы авторизовались на сайте банка, а затем перешли на другой, вредоносный сайт — и этот сайт может скрытно отправить запрос на перевод денег в банк от вашего имени.

Современные решения:

1. CSRF-токены: такие фреймворки, как Django, требуют секретный csrf_token для каждой формы.
2. SameSite Cookie: атрибуты SameSite=Lax или SameSite=Strict для файлов cookie предотвращают их отправку вместе с запросами с посторонних сайтов.

5. Почему нельзя использовать MD5 или SHA256 для хранения паролей?

Многие начинающие разработчики считают, что достаточно сохранить пароль в базу данных как md5(password). Это крайне опасное заблуждение! Алгоритмы MD5 и даже стандартный SHA256 работают слишком быстро. С помощью современных видеокарт (GPU) можно перебирать миллиарды комбинаций в секунду и восстановить пароль за считанные минуты (методом радужных таблиц или брутфорсом).

Для паролей необходимо использовать исключительно медленные и специально разработанные алгоритмы хеширования: bcrypt, Argon2 или PBKDF2. Они добавляют к паролю специальную «соль» (salt) и намеренно замедляют процесс вычислений, делая атаки методом перебора практически невозможными.

6. Полностью ли ORM решает проблему SQL-инъекций?

Многие разработчики питают иллюзии: «Я использую Django ORM или Prisma, значит, в моем проекте не может быть SQL-инъекций». Действительно, благодаря использованию подготовленных параметризованных запросов (prepared statements) ORM полностью исключает типичные SQL-инъекции.

Однако если разработчик использует сырые SQL-запросы и конкатенирует или форматирует пользовательские данные напрямую в строку запроса, уязвимость возвращается:

# XAVFLI KOD (SQL Injection xavfi bor):
query = f"SELECT * FROM users WHERE username = '{user_input}'"
User.objects.raw(query)

# XAVFSIZ KOD:
User.objects.raw("SELECT * FROM users WHERE username = %s", [user_input])

Никогда не подставляйте значения от пользователя напрямую в строку SQL-запроса!

7. Почему HTTPS и SSL — это не просто значок замка возле домена?

Некоторые считают, что HTTPS нужен только на страницах ввода паролей или данных банковских карт. На самом деле весь веб-сайт должен работать по протоколу HTTPS. HTTPS шифрует данные между пользователем и сервером. Без HTTPS:

• В публичных сетях Wi-Fi (например, в кафе) злоумышленник, реализующий атаку Man-in-the-Middle («человек посередине»), может в открытом виде перехватить все данные пользователей.
• Провайдеры или злоумышленники могут внедрять свою рекламу или вредоносные скрипты в код страниц вашего сайта.
• Поисковая система Google пессимизирует сайты на HTTP в результатах поиска, а браузеры показывают предупреждение «Не защищено».

Сегодня с помощью Let's Encrypt и Certbot можно совершенно бесплатно установить SSL-сертификат на любой Linux-сервер за считанные минуты.

Заключение

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