Защита форм регистрации и комментариев от CSRF

Я прочитал много статей о защите CSRF ( это хороший ) и различные вопросы здесь, на SO, но ни один из них, похоже, недостаточно информативен для ответа на мой вопрос.

Я разрабатываю свою собственную CMS, и я хочу защитить свои формы входа и комментариев. Я позволю анонимным пользователям прокомментировать мой сайт.

Все формы на моем сайте защищены с помощью токенов. Я уже знаю об этом подходе, но проблема в том, что ему нужен активный сеанс (то есть после входа пользователя в систему). Проблема с форматами входа и комментариев заключается в том, что они доступны для всех и не требуют входа в систему – какая будет лучшая защита от CSRF в этом случае?

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

Заголовок referrer является слабым решением, поэтому я не должен беспокоиться. Заголовок Origin, насколько я уже протестировал, поддерживается только в Google Chrome. Как насчет пользовательских заголовков? XMLHTTPRequest похоже на возможность, однако я потратил буквально более трех часов на поиск Google некоторой информации о том, как реализовать такую ​​меру безопасности на своем веб-сайте. Но даже если бы я мог использовать пользовательский заголовок, не делает его бесполезным, поскольку заголовки HTTP могут быть полностью фальшивыми?

Итак, вопрос: как я должен защищать свои формы входа и комментариев против CSRF?

Изменить: вот дополнительная информация из приведенной выше ссылки:

Мы рекомендуем строгое подтверждение Referer для защиты от входа в систему CSRF, поскольку формы входа обычно передаются через HTTPS, где заголовок Referer надежно присутствует для законных запросов. Если в запросе на вход пользователя отсутствует заголовок Referer, сайт должен отклонить запрос на защиту от вредоносного подавления.

а также

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

Я просто не могу положить конец этому аргументу после прочтения приведенных выше цитат. Один из них упоминает использование заголовка referrer, но я не совсем уверен, действительно ли это добавляет к безопасности webapp.

Изменить 2: Как насчет использования CAPTCHA?