--- title: Безопасность веб-приложений questionDates: q-transfer-0234: '2026-10-01' q-transfer-0235: '2026-10-01' q-transfer-0236: '2026-10-01' q-transfer-0237: '2026-10-01' q-transfer-0238: '2026-10-01' q-transfer-0269: '2026-10-01' q-transfer-0270: '2026-10-01' q-transfer-0271: '2026-10-01' seo: description: >- Тема «Безопасность веб-приложений» для собеседования Python Developer. Как безопасно хранить пароли? Какие меры нужны HTTP API помимо HTTPS? title: Безопасность веб-приложений — Python Developer --- [Все темы Python Developer](/prep/python-developer) ## Как безопасно хранить пароли? [#q-transfer-0234] Пароль хранят как результат медленной password-hashing функции, например Argon2id, scrypt или bcrypt, с уникальной случайной salt и параметрами стоимости. При входе библиотека повторяет вычисление и сравнивает результат; исходный пароль восстановить нельзя. Параметры со временем повышают и rehash выполняют после успешной проверки. Обратимое шифрование и быстрые SHA-хеши не подходят; pepper можно хранить отдельно как дополнительную защиту. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента. :::note[Ссылки для изучения] 1. [Хеширование и проверка паролей в Python: Argon2 и pwdlib — документация FastAPI](https://fastapi.tiangolo.com/ru/tutorial/security/oauth2-jwt/) ::: --- ## Какие меры нужны HTTP API помимо HTTPS? [#q-transfer-0235] HTTPS защищает канал, но API еще нужны аутентификация и проверка права на конкретный объект, строгая валидация, лимиты размера и частоты, таймауты и безопасные CORS-настройки. Ошибки не должны раскрывать внутренности, а логи содержать токены и пароли. Для cookie-аутентификации учитывают CSRF, для bearer-токенов защищают их хранение. Зависимости обновляют, а чувствительные операции журналируют. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента. :::note[Ссылки для изучения] 1. [Безопасность Python веб-приложения: CSRF, SQL-инъекции, файлы и секреты — Django](https://djangodoc.ru/5.0/topics/security/) ::: --- ## Чем серверная сессия отличается от cookie? [#q-transfer-0236] Cookie является данными, которые браузер хранит и отправляет серверу. При серверной сессии cookie обычно содержит только непредсказуемый идентификатор, а состояние и возможность отзыва находятся на сервере. После входа ID ротируют, задают `Secure`, `HttpOnly`, подходящий `SameSite` и срок жизни, чтобы снизить риск session fixation и кражи. Подписанный cookie может хранить состояние на клиенте, но подпись не скрывает содержимое. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента. :::note[Ссылки для изучения] 1. [Серверные сессии и подписанные cookie в Django: хранение данных и смена ключа](https://djangodoc.ru/5.0/topics/http/sessions/) 2. [Серверная сессия. Сергей Соловьев, с 42:32](https://www.youtube.com/watch?v=QacZVserfIU&t=2552s) ::: --- ## Как устроен multipart/form-data для загрузки файла? [#q-transfer-0237] `multipart/form-data` делит тело boundary-маркерами на именованные части. У файловой части есть `Content-Disposition` с именем поля и filename, иногда `Content-Type`, затем идут байты. Сервер должен потоково ограничивать общий размер и число частей, не доверять filename и заявленному MIME, проверять содержимое и сохранять под собственным именем вне исполняемого каталога. Boundary берут из заголовка, а не угадывают. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента. :::note[Ссылки для изучения] 1. [Устройство multipart/form-data: boundary и части текстового поля и файла — MDN](https://developer.mozilla.org/ru/docs/Web/HTTP/Reference/Headers/Content-Type) ::: --- ## Почему десериализацию внешних данных нужно отделять от валидации? [#q-transfer-0238] Десериализация отвечает за синтаксис и преобразование формата в базовые значения. Валидация отдельно проверяет схему, типы, диапазоны и бизнес-правила. Такое разделение позволяет отличить битый JSON от корректного, но недопустимого заказа, и не наделяет parser лишним доверием. Небезопасные форматы, способные создавать произвольные объекты, например недоверенный `pickle`, нельзя использовать даже с последующей валидацией. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента. :::note[Ссылки для изучения] 1. [Чтение JSON и проверка данных по схеме — официальный учебник FastAPI](https://fastapi.tiangolo.com/ru/tutorial/body/) ::: --- ## Как устроен OAuth 2.0 authorization code flow? [#q-transfer-0269] Клиент отправляет пользователя на authorization endpoint с `redirect_uri`, `state` и PKCE challenge. После согласия authorization server возвращает короткоживущий code; клиент меняет его на токены по защищенному каналу, предъявляя verifier. `state` связывает ответ с запросом и защищает от подмены потока, PKCE от перехвата code. OAuth 2.0 делегирует авторизацию; идентификацию пользователя поверх него обычно задает OpenID Connect. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента. :::note[Ссылки для изучения] 1. [Authorization code flow, state и PKCE — официальная документация Яндекс ID](https://yandex.ru/dev/id/doc/ru/codes/code-url) ::: --- ## Как устроена аутентификация Django? [#q-transfer-0270] Django аутентифицирует credentials через настроенные authentication backends и связывает результат с User model. После login идентификатор пользователя хранится в серверной сессии, а `AuthenticationMiddleware` выставляет `request.user`. Permissions проверяют право выполнить действие, но объектные права зависят от backend или приложения. При cookie-сессии изменяющие запросы защищает CSRF-механизм; он решает другую задачу, чем вход пользователя. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента. :::note[Ссылки для изучения] 1. [Аутентификация Django через authenticate и login: проверка пользователя и запись сессии](https://proproprogs.ru/django4/django4-avtorizaciya-polzovateley-funkcii-authenticate-i-login) ::: --- ## Когда выбрать серверную сессию вместо JWT? [#q-transfer-0271] Серверная сессия удобна, когда нужен немедленный отзыв, централизованный контроль устройств и небольшое состояние входа. Cookie хранит opaque ID, а серверное хранилище требует доступности, очистки и масштабирования. JWT удобен для автономной проверки между сервисами, но отзыв и обновление прав сложнее до истечения срока. Подписанный JWT не зашифрован по умолчанию, поэтому секреты в payload не кладут. Защиту проверяют на границе доверия и отказе, не полагаясь на секретность формата или добросовестность клиента. :::note[Ссылки для изучения] 1. [Немедленный отзыв доступа: состояние сервера, JWT и записи сессий — JSTools / Timeweb Cloud](https://habr.com/ru/companies/timeweb/articles/1077690/) :::