Каковы некоторые жизнеспособные методы для объединения защиты CSRF с API-интерфейсами RESTful?

Мне интересно услышать, какие подходы люди использовали при создании RESTful (или квази-RESTful) API для своих веб-приложений.

Практический пример:

Допустим, у вас есть традиционное веб-приложение на основе браузера, которое использует защиту CSRF во всех формах. Скрытый ввод с токеном защиты CSRF включен в каждую форму, представленную в браузере. При отправке формы, если этот ввод не соответствует версии токена на стороне сервера, форма считается недействительной.

Теперь предположим, что вы хотите представить веб-приложение как API (возможно, используя JSON вместо HTML). Традиционно при публикации API я считал транзакции односторонними (имеется в виду, что потребитель API строит запрос на основе опубликованного API, а не сначала запрашивает форму, а затем строит запрос с использованием возвращенной формы).

«Односторонний» подход ломается, когда в него входят такие факторы, как фактор защиты CSRF. Маркер защиты CSRF должен быть включен в любые сообщения POSTS / PUTS / DELETES, отправленные потребителем API.

Я пытался придумать, как лучше решить эту проблему. Запрос формы каждый раз, когда требуется выполнить вызов API, кажется очень неловким (особенно при работе с асинхронными операциями), но все другие альтернативы, о которых я думал, по-моему, побеждают защиту CSRF (или, по крайней мере, пробивают в ней дыры). ), что недопустимо.

Кто-нибудь из вас понимает это?

Благодарю.

(Не то чтобы это должно было иметь большое значение, поскольку проблема концептуальна и не зависит от платформы, но я имею дело с традиционным стеком LAMP и использую Symfony 1.4 в качестве моей прикладной среды. Моя цель - опубликовать веб-API в формате JSON, позволяющий разработчикам создавать мобильные / настольные приложения, которые хорошо играют с существующим веб-приложением.)

Ответы на вопрос(1)

Ваш ответ на вопрос