Clarify CSRF <script> purpose and protection. Note how to deal with your own <script> tags.

Ref #21618

[ci skip]

1 files changed, 8 insertions, 5 deletions

diff --git a/guides/source/upgrading_ruby_on_rails.md b/guides/source/upgrading_ruby_on_rails.md
index 2de9d6045e..52464a1c51 100644
--- a/guides/source/upgrading_ruby_on_rails.md
+++ b/guides/source/upgrading_ruby_on_rails.md
@@ -314,11 +314,13 @@ Upgrading from Rails 4.0 to Rails 4.1
 
 ### CSRF protection from remote `<script>` tags
 
-Or, "whaaat my tests are failing!!!?"
+Or, "whaaat my tests are failing!!!?" or "my `<script>` widget is busted!!"
 
-Cross-site request forgery (CSRF) protection now covers GET requests with dynamic JavaScript responses, too. By default, all javascript responses generated by an action will be blocked for non xhr requests. This will block usage of such urls in any `<script>` tag including your own. That way, in a possible attack scenario, it prevents a third-party site from referencing your JavaScript URL and attempting to run it to extract sensitive data.
+Cross-site request forgery (CSRF) protection now covers GET requests with
+JavaScript responses, too. This prevents a third-party site from remotely
+referencing your JavaScript with a `<script>` tag to extract sensitive data.
 
-It also means that your functional and integration tests that use
+This means that your functional and integration tests that use
 
 ```ruby
 get :index, format: :js
@@ -332,8 +334,9 @@ xhr :get, :index, format: :js
 
 to explicitly test an `XmlHttpRequest`.
 
-If you really mean to load JavaScript from remote `<script>` tags, skip CSRF
-protection on that action.
+Note: Your own `<script>` tags are treated as cross-origin and blocked by
+default, too. If you really mean to load JavaScript from `<script>` tags,
+you must now explicitly skip CSRF protection on those actions.
 
 ### Spring