Merge pull request #31640 from gingerlime/patch-1

fixes #27157 CSRF protection documentation

1 files changed, 11 insertions, 4 deletions

diff --git a/actionpack/lib/action_controller/metal/request_forgery_protection.rb b/actionpack/lib/action_controller/metal/request_forgery_protection.rb
index edfef39771..ea637c8150 100644
--- a/actionpack/lib/action_controller/metal/request_forgery_protection.rb
+++ b/actionpack/lib/action_controller/metal/request_forgery_protection.rb
@@ -17,7 +17,7 @@ module ActionController #:nodoc:
   # access. When a request reaches your application, \Rails verifies the received
   # token with the token in the session. All requests are checked except GET requests
   # as these should be idempotent. Keep in mind that all session-oriented requests
-  # should be CSRF protected, including JavaScript and HTML requests.
+  # are CSRF protected by default, including JavaScript and HTML requests.
   #
   # Since HTML and JavaScript requests are typically made from the browser, we
   # need to ensure to verify request authenticity for the web browser. We can
@@ -30,16 +30,23 @@ module ActionController #:nodoc:
   # URL on your site. When your JavaScript response loads on their site, it executes.
   # With carefully crafted JavaScript on their end, sensitive data in your JavaScript
   # response may be extracted. To prevent this, only XmlHttpRequest (known as XHR or
-  # Ajax) requests are allowed to make GET requests for JavaScript responses.
+  # Ajax) requests are allowed to make requests for JavaScript responses.
   #
-  # It's important to remember that XML or JSON requests are also affected and if
-  # you're building an API you should change forgery protection method in
+  # It's important to remember that XML or JSON requests are also checked by default. If
+  # you're building an API or an SPA you could change forgery protection method in
   # <tt>ApplicationController</tt> (by default: <tt>:exception</tt>):
   #
   #   class ApplicationController < ActionController::Base
   #     protect_from_forgery unless: -> { request.format.json? }
   #   end
   #
+  # It is generally safe to exclude XHR requests from CSRF protection
+  # (like the code snippet above does), because XHR requests can only be made from
+  # the same origin. Note however that any cross-origin third party domain
+  # allowed via {CORS}[https://en.wikipedia.org/wiki/Cross-origin_resource_sharing]
+  # will also be able to create XHR requests. Be sure to check your
+  # CORS whitelist before disabling forgery protection for XHR.
+  # 
   # CSRF protection is turned on with the <tt>protect_from_forgery</tt> method.
   # By default <tt>protect_from_forgery</tt> protects your session with
   # <tt>:null_session</tt> method, which provides an empty session