XSS возникает, когда недоверенные данные становятся исполняемым кодом в контексте HTML, атрибута, URL, CSS или JavaScript. Основная защита — безопасный вывод для конкретного контекста и отказ от опасных DOM API; sanitization нужна только там, где разрешён HTML. CSP уменьшает последствия и помогает обнаруживать нарушения, но не заменяет исправление источника.
Читать статью
SQL-инъекция появляется, когда данные пользователя меняют структуру SQL-команды. Основная защита — параметризованный запрос, в котором текст операции и значения передаются раздельно. ORM помогает только при использовании безопасного API: raw SQL, динамические имена колонок и строковая сборка возвращают риск. Дополнительную глубину дают allowlist и минимальные права учётной записи БД.
Читать статью
CSRF использует способность браузера автоматически приложить cookie к запросу на доверенный сайт. Сервер видит действующую сессию, но без дополнительного доказательства не знает, инициировал ли действие сам пользователь. Защита сочетает встроенный механизм фреймворка, CSRF-токен для изменяющих запросов, SameSite-cookie, проверку Origin и отдельное подтверждение критичных операций.
Читать статью
Серверная сессия хранит состояние на стороне приложения и передаёт браузеру непрозрачный идентификатор. JWT переносит подписанные claims в сам токен, но не решает автоматически хранение, отзыв, ротацию и авторизацию. Для обычного сайта с браузером сессия часто проще; JWT оправдан в распределённых API, когда его ограничения приняты осознанно.
Читать статью
OAuth 2.0 делегирует ограниченный доступ к ресурсу, а OpenID Connect добавляет стандартизованный слой аутентификации и ID Token. Кнопка «Войти через…» должна строиться как OIDC-поток с Authorization Code и PKCE, строгими redirect URI, state и nonce, серверной проверкой токенов и понятной связью внешней учётной записи с внутренним пользователем.
Читать статью
MFA требует доказательств из разных категорий, а не двух паролей. Наибольшую устойчивость к фишингу дают криптографические факторы вроде passkeys и аппаратных ключей; TOTP остаётся практичным переходным вариантом. Безопасность внедрения определяется не только входом, но и подключением, сменой, резервными кодами и восстановлением доступа.
Читать статью
Пароли не шифруют для последующей расшифровки и не пропускают через быстрый общий хеш. Сервер хранит результат специально замедленной password-hashing функции с уникальной солью и параметрами стоимости. Алгоритм и параметры версионируют, старые записи обновляют при успешном входе, а pepper при использовании держат отдельно от базы.
Читать статью
CORS — механизм HTTP-заголовков, с помощью которого сервер разрешает браузерному JavaScript читать ответы с другого origin. Он не является системой аутентификации, не запрещает серверные запросы и не заменяет CSRF-защиту. Безопасная конфигурация открывает только нужные endpoints, origins, методы и заголовки и корректно обрабатывает preflight и credentials.
Читать статью
Загружаемый файл — недоверенный ввод, который может содержать исполняемый код, полиглот, архив-бомбу, вредоносный документ или опасное имя. Надёжный pipeline ограничивает бизнес-допустимые типы и размер, проверяет содержимое несколькими способами, генерирует новое имя, помещает объект в карантин и выдаёт его из отдельного хранилища с безопасными заголовками.
Читать статью
Аутентификация подтверждает, кто обращается к системе, а авторизация решает, разрешено ли этому субъекту конкретное действие над конкретным объектом. Безопасная архитектура не ограничивается формой входа: она связывает идентичность, жизненный цикл сессии, серверную проверку прав, повторную аутентификацию для рискованных операций и аудит решений доступа.
Читать статью
Транзакция объединяет связанные изменения базы в одну логическую операцию: они подтверждаются вместе или отменяются. ACID не исправляет неверную бизнес-логику автоматически — команда должна выбрать границы операции, ограничения данных, уровень изоляции и безопасное поведение при конфликте или повторе запроса.
Читать статью
REST API — контракт между клиентом и сервером, построенный вокруг ресурсов и стандартной семантики HTTP. Надёжность определяется не форматом JSON, а предсказуемыми адресами, методами, кодами ответа, проверкой прав, повторяемостью операций и правилами совместимых изменений.
Читать статью