1 files changed, 13 insertions, 13 deletions

diff --git a/guides/source/security.md b/guides/source/security.md
index 2f9aebae9b..5ef68d2272 100644
--- a/guides/source/security.md
+++ b/guides/source/security.md
@@ -96,8 +96,8 @@ That means the security of this storage depends on this secret (and on the diges
 
 ```ruby
 config.action_dispatch.session = {
-  :key    => '_app_session',
-  :secret => '0x0dkfj3927dkc7djdh36rkckdfzsg...'
+  key:    '_app_session',
+  secret: '0x0dkfj3927dkc7djdh36rkckdfzsg...'
 }
 ```
 
@@ -233,7 +233,7 @@ Or the attacker places the code into the onmouseover event handler of an image:
 There are many other possibilities, including Ajax to attack the victim in the background.
The _solution to this is including a security token in non-GET requests_ which check on the server-side. In Rails 2 or higher, this is a one-liner in the application controller:
 
 ```ruby
-protect_from_forgery :secret => "123456789012345678901234567890..."
+protect_from_forgery secret: "123456789012345678901234567890..."
 ```
 
 This will automatically include a security token, calculated from the current session and the server-side secret, in all forms and Ajax requests generated by Rails. You won't need the secret, if you use CookieStorage as session storage. If the security token doesn't match what was expected, the session will be reset. **Note:** In Rails versions prior to 3.0.4, this raised an `ActionController::InvalidAuthenticityToken` error.
@@ -264,7 +264,7 @@ Whenever the user is allowed to pass (parts of) the URL for redirection, it is p
 
 ```ruby
 def legacy
-  redirect_to(params.update(:action=>'main'))
+  redirect_to(params.update(action:'main'))
 end
 ```
 
@@ -334,7 +334,7 @@ basename = File.expand_path(File.join(File.dirname(__FILE__), '../../files'))
 filename = File.expand_path(File.join(basename, @file.public_filename))
 raise if basename !=
      File.expand_path(File.join(File.dirname(filename), '../../../'))
-send_file filename, :disposition => 'inline'
+send_file filename, disposition: 'inline'
 ```
 
 Another (additional) approach is to store the file names in the database and name the files on the disk after the ids in the database. This is also a good approach to avoid possible code in an uploaded file to be executed. The attachment_fu plugin does this in a similar way.
@@ -383,7 +383,7 @@ any model's attributes by manipulating the hash passed to a model's `new()` meth
 
 ```ruby
 def signup
-  params[:user] # => {:name=>"ow3ned", :admin=>true}
+  params[:user] # => {name:"ow3ned", admin:true}
   @user = User.new(params[:user])
 end
 ```
@@ -402,7 +402,7 @@ http://www.example.com/user/signup?user[name]=ow3ned&user[admin]=1
 This will set the following parameters in the controller:
 
 ```ruby
-params[:user] # => {:name=>"ow3ned", :admin=>true}
+params[:user] # => {name:"ow3ned", admin:true}
 ```
 
 So if you create a new user using mass-assignment, it may be too easy to become
@@ -459,9 +459,9 @@ should be allowed for mass updating using the slice pattern. For example:
 ```ruby
 def signup
   params[:user]
-  # => {:name=>"ow3ned", :admin=>true}
+  # => {name:"ow3ned", admin:true}
   permitted_params = params.require(:user).permit(:name)
-  # => {:name=>"ow3ned"}
+  # => {name:"ow3ned"}
 
   @user = User.new(permitted_params)
 end
@@ -648,7 +648,7 @@ Since this is a frequent mistake, the format validator (validates_format_of) now
 
 ```ruby
   # content should include a line "Meanwhile" anywhere in the string
-  validates :content, :format => { :with => /^Meanwhile$/, :multiline => true }
+  validates :content, format: { with: /^Meanwhile$/, multiline: true }
 ```
 
 Note that this only protects you against the most common mistake when using the format validator - you always need to keep in mind that ^ and $ match the **line** beginning and line end in Ruby, and not the beginning and end of a string.
@@ -686,7 +686,7 @@ NOTE: _When sanitizing, protecting or verifying something, whitelists over black
 
 A blacklist can be a list of bad e-mail addresses, non-public actions or bad HTML tags. This is opposed to a whitelist which lists the good e-mail addresses, public actions, good HTML tags and so on. Although sometimes it is not possible to create a whitelist (in a SPAM filter, for example), _prefer to use whitelist approaches_:
 
-* Use before_filter :only => [...] instead of :except => [...]. This way you don't forget to turn it off for newly added actions.
+* Use before_filter only: [...] instead of except: [...]. This way you don't forget to turn it off for newly added actions.
 * Use attr_accessible instead of attr_protected. See the mass-assignment section for details
 * Allow <strong> instead of removing <script> against Cross-Site Scripting (XSS). See below for details.
 * Don't try to correct user input by blacklists:
@@ -769,7 +769,7 @@ Model.where("login = ? AND password = ?", entered_user_name, entered_password).f
 As you can see, the first part of the array is an SQL fragment with question marks. The sanitized versions of the variables in the second part of the array replace the question marks. Or you can pass a hash for the same result:
 
 ```ruby
-Model.where(:login => entered_user_name, :password => entered_password).first
+Model.where(login: entered_user_name, password: entered_password).first
 ```
 
 The array or hash form is only available in model instances. You can try `sanitize_sql()` elsewhere. _Make it a habit to think about the security consequences when using an external string in SQL_.
@@ -864,7 +864,7 @@ This returned "some<script>alert('hello')</script>", which makes an
 
 ```ruby
 tags = %w(a acronym b strong i em li ul ol h1 h2 h3 h4 h5 h6 blockquote br cite sub sup ins p)
-s = sanitize(user_input, :tags => tags, :attributes => %w(href title))
+s = sanitize(user_input, tags: tags, attributes: %w(href title))
 ```
 
 This allows only the given tags and does a good job, even against all kinds of tricks and malformed tags.