fixes #27157 CSRF protection documentation
* removed reference to GET requests where it applies also to other HTTP verbs * updated documentation to try and better explain how CSRF protection works with XHR, and the potential exposure with CORS
This commit is contained in:
parent
5a50146888
commit
c3787494ed
|
@ -18,7 +18,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
|
||||
|
@ -31,16 +31,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
|
||||
|
|
Loading…
Reference in New Issue