Допустим вы зашли в свою почту на сайте example.com. Интерфейс почтовой системы имеет кнопку Log out, которая вызывает URL example.com/logout. Таким образом для того, чтобы выйти из своей почты достаточно посетить страницу example.com/logout.

Вредоносный сайт может заставить вас посетить URL example.com/logout с помощью скрытого тега <iframe> на своей странице. Таким образом, если вы были авторизованы на почтовом интерфейсе example.com и посетили вредоносную страницу, которая выполнила через <iframe> обращение к example.com/logout, ваша авторизация на почтовом интерфейсе будет прекращена.

Очевидно, что выход из почтового интерфейса вопреки вашей воли не является ужасающем нарушением безопасности, но этот же подход может использоваться для любого сайта, который «доверяет» своим посетителям, например, сайт банка или электронного алгоритма.

В предыдущем примере сайт example.com был частично скомпрометирован, потому что он позволял изменять состояние (т.е. отменять авторизацию пользователя) через GET запрос. Более практично требовать POST запрос для изменения состояния на сайте. Но даже это не спасёт полностью от CSRF.

Предположим, что на сайте example.com провели обновление функциональность и теперь для отмены авторизации пользователя требуется нажать кнопку на форме, которая отправит POST запрос к example.com/logout. Более того, форма содержит скрытое поле:

<input type="hidden" name="confirm" value="true" />

Это даёт гарантию, что обычный POST запрос к example.com/logout не отменит авторизацию пользователя, для этого ещё должна передаваться переменная confirm со значением true.

Несмотря на дополнительную безопасность этот механизм всё ещё может быть скомпрометирован CSRF — вредоносной странице просто потребуется сделать чуть больше работы. Атакующие могут создать целую форму для вашего сайта, спрятав её в невидимом <iframe>, а затем использовать JavaScript для автоматической отправки этой формы.

Как может ваш сайт защитить себя от этого типа атак? Первым шагом будет проверка того, что все GET запросы не содержат побочные эффекты. Затем, если вредоносный сайт включает одну из ваших страниц в <iframe>, это не будет приводить к негативному эффекту.

Остались POST запросы. Вторым шагом будет добавление в каждую форму скрытого поля, значение которого генерируется из идентификатора пользователя. Затем, при обработки формы на стороне сервера, следует проверять это поле и выдавать ошибку, если проверка не удастся.

Именно это и делает Django для предотвращения CSRF. А подробности далее.