CORS, CSRF, XSS
Тема дорожной карты · Backend разработчик
CORS (Cross-Origin Resource Sharing) — механизм браузера, который контролирует, каким образом веб-страницы могут запрашивать ресурсы с других доменов. Сервер разрешает или запрещает кросс-доменные запросы через HTTP-заголовки: Access-Control-Allow-Origin задаёт разрешённые источники, Access-Control-Allow-Methods — HTTP-методы, а Access-Control-Allow-Headers — допустимые заголовки. Для предварительных (preflight) запросов браузер отправляет метод OPTIONS перед реальным запросом — сервер должен корректно на него отвечать. Неправильная настройка CORS может привести к CSRF-уязвимостям, поэтому не следует использовать Access-Control-Allow-Origin: * для защищённых API-эндпоинтов.
Как это работает
CORS, CSRF, XSS включает аутентификацию (кто вы?) и авторизацию (что можете?). Современная 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 с первого дня.
Типичные ошибки
Ловушки CORS, CSRF, XSS: пароли через MD5/SHA1/SHA256 (быстро, brute-force-friendly — используйте argon2id); JWT-секрет в клиентском коде или git-history; JWT без expiry или revocation list (потерянный девайс = пожизненный доступ к аккаунту); своя крипта (используйте библиотеки); admin-endpoints без auth "потому что internal" (внутренняя сеть не граница безопасности). Регулярные auth-аудиты.