> For the complete documentation index, see [llms.txt](https://ilyachch.gitbook.io/django-rest-framework-russian-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ilyachch.gitbook.io/django-rest-framework-russian-documentation/stati/topics/ajax-csrf-cors.md).

# AJAX, CSRF & CORS

> "Внимательно изучите возможные уязвимости CSRF / XSRF на ваших собственных сайтах. Это худший вид уязвимостей - их очень легко использовать злоумышленникам, но не так просто интуитивно понять разработчикам программного обеспечения, по крайней мере, пока вас не укусит одна из них."
>
> * [Jeff Atwood](https://blog.codinghorror.com/preventing-csrf-and-xsrf-attacks/)

## Клиенты Javascript

Если вы создаете JavaScript-клиент для взаимодействия с вашим Web API, вам нужно подумать, может ли клиент использовать ту же политику аутентификации, которая используется остальной частью сайта, а также определить, нужно ли вам использовать CSRF-токены или CORS-заголовки.

AJAX-запросы, выполняемые в том же контексте, что и API, с которым они взаимодействуют, обычно используют `SessionAuthentication`. Это гарантирует, что после того, как пользователь вошел в систему, любые запросы AJAX могут быть аутентифицированы с помощью той же сеансовой аутентификации, которая используется для остальной части сайта.

AJAX-запросы, которые выполняются на сайте, отличном от сайта API, с которым они взаимодействуют, обычно должны использовать схему аутентификации, не основанную на сеансах, например `TokenAuthentication`.

## Защита от CSRF

[Защита от подделки межсайтовых запросов](https://owasp.org/www-community/attacks/csrf) - это механизм защиты от определенного типа атак, которые могут возникнуть, когда пользователь не вышел с веб-сайта и продолжает иметь действующую сессию. В этом случае вредоносный сайт может выполнить действия против целевого сайта в контексте вошедшей сессии.

Чтобы защититься от такого рода атак, вам нужно сделать две вещи:

1. Убедитесь, что "безопасные" операции HTTP, такие как `GET`, `HEAD` и `OPTIONS`, не могут быть использованы для изменения состояния на стороне сервера.
2. Убедитесь, что для любых "небезопасных" операций HTTP, таких как `POST`, `PUT`, `PATCH` и `DELETE`, всегда требуется действительный токен CSRF.

Если вы используете `SessionAuthentication`, вам необходимо включить действительные CSRF-токены для любых операций `POST`, `PUT`, `PATCH` или `DELETE`.

Чтобы выполнять AJAX-запросы, необходимо включить CSRF-токен в HTTP-заголовок, как [описано в документации Django](https://docs.djangoproject.com/en/stable/howto/csrf/#using-csrf-protection-with-ajax).

## CORS

[Cross-Origin Resource Sharing](https://www.w3.org/TR/cors/) - это механизм, позволяющий клиентам взаимодействовать с API, размещенными на другом домене. CORS работает, требуя от сервера включения определенного набора заголовков, которые позволяют браузеру определить, разрешены ли междоменные запросы и когда они должны быть разрешены.

Лучший способ справиться с CORS в DRF - добавить необходимые заголовки ответа в middleware. Это гарантирует, что CORS поддерживается прозрачно, без необходимости изменять какое-либо поведение в ваших представлениях.

[Adam Johnson](https://github.com/adamchainz) поддерживает пакет [django-cors-headers](https://github.com/adamchainz/django-cors-headers), который, как известно, корректно работает с API DRF.