Аутентификация и безопасность
Тема дорожной карты · Backend разработчик
Безопасность бэкенда охватывает полный спектр практик, протоколов и средств контроля, защищающих серверные приложения от несанкционированного доступа, утечек данных и злоупотреблений. Аутентификация является основой: современные бэкенды используют JWT bearer-токены, выдаваемые сервером авторизации OAuth 2.0 / OpenID Connect, или сессионные куки, защищённые флагами HttpOnly, Secure и SameSite=Strict, предотвращающими эксплуатацию через XSS и CSRF. Безопасность транспорта требует TLS 1.2+ везде — обеспечивается обратными прокси Nginx или Caddy — с заголовками HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains) для предотвращения атак на понижение протокола. Валидация входных данных и параметризованные запросы в PostgreSQL (плейсхолдеры $1, $2) или MySQL (плейсхолдеры ? с PreparedStatement) — основная защита от SQL-инъекций, тогда как заголовки Content-Security-Policy, экранирование вывода и middleware helmet в Express.js защищают от XSS. Для полноценной безопасности бэкенда необходимы управление секретами через HashiCorp Vault или AWS Secrets Manager, сканирование зависимостей с npm audit или pip-audit, ограничение частоты запросов на эндпоинтах аутентификации и регулярное тестирование на проникновение по методологии OWASP Top 10.
Как это работает
Аутентификация и безопасность включает аутентификацию (кто вы?) и авторизацию (что можете?). Современная auth: OAuth 2.0 + OpenID Connect для делегированной identity, session-куки для традиционных веб-приложений, JWT для stateless distributed-систем. Пароли всегда хешируйте через bcrypt или argon2id. CSRF-защита на state-changing endpoints; CORS осознанно (не * в production). Авторизация: RBAC (роли), ABAC (атрибуты), policy engines (OPA, Casbin). MFA/2FA для любой привилегированной операции.
Когда применять
Session-куки — для монолитных веб-приложений (HttpOnly + Secure + SameSite=Lax): проще, отзываемо, server-side state. JWT — только когда реально нужна stateless distributed-валидация; иначе session безопаснее. Identity отдавайте провайдеру (Yandex ID, Keycloak, Auth0, Authentik) — DIY identity = место утечек. Rate-limit на auth-endpoints с первого дня.
Типичные ошибки
Ловушки Аутентификация и безопасность: пароли через MD5/SHA1/SHA256 (быстро, brute-force-friendly — используйте argon2id); JWT-секрет в клиентском коде или git-history; JWT без expiry или revocation list (потерянный девайс = пожизненный доступ к аккаунту); своя крипта (используйте библиотеки); admin-endpoints без auth "потому что internal" (внутренняя сеть не граница безопасности). Регулярные auth-аудиты.