[ci skip] change all instances of blacklist and whitelist to denylist and allowlist

11 files changed, 40 insertions, 40 deletions

diff --git a/guides/source/4_0_release_notes.md b/guides/source/4_0_release_notes.md
index eaae695dff..4f437da2b8 100644
--- a/guides/source/4_0_release_notes.md
+++ b/guides/source/4_0_release_notes.md
@@ -70,7 +70,7 @@ Major Features
 
 ### ActionPack
 
-* **Strong parameters** ([commit](https://github.com/rails/rails/commit/a8f6d5c6450a7fe058348a7f10a908352bb6c7fc)) - Only allow whitelisted parameters to update model objects (`params.permit(:title, :text)`).
+* **Strong parameters** ([commit](https://github.com/rails/rails/commit/a8f6d5c6450a7fe058348a7f10a908352bb6c7fc)) - Only allow allowlisted parameters to update model objects (`params.permit(:title, :text)`).
 * **Routing concerns** ([commit](https://github.com/rails/rails/commit/0dd24728a088fcb4ae616bb5d62734aca5276b1b)) - In the routing DSL, factor out common subroutes (`comments` from `/posts/1/comments` and `/videos/1/comments`).
 * **ActionController::Live** ([commit](https://github.com/rails/rails/commit/af0a9f9eefaee3a8120cfd8d05cbc431af376da3)) - Stream JSON with `response.stream`.
 * **Declarative ETags** ([commit](https://github.com/rails/rails/commit/ed5c938fa36995f06d4917d9543ba78ed506bb8d)) - Add controller-level etag additions that will be part of the action etag computation.
diff --git a/guides/source/4_1_release_notes.md b/guides/source/4_1_release_notes.md
index 0c7bd01cac..f0d40985fe 100644
--- a/guides/source/4_1_release_notes.md
+++ b/guides/source/4_1_release_notes.md
@@ -719,7 +719,7 @@ for detailed changes.
   responsibilities within a
   class. ([Commit](https://github.com/rails/rails/commit/1eee0ca6de975b42524105a59e0521d18b38ab81))
 
-* Added `Object#presence_in` to simplify value whitelisting.
+* Added `Object#presence_in` to simplify value allowlisting.
   ([Commit](https://github.com/rails/rails/commit/4edca106daacc5a159289eae255207d160f22396))
 
 
diff --git a/guides/source/action_controller_overview.md b/guides/source/action_controller_overview.md
index 7ce1f5c2a3..58c1d5494c 100644
--- a/guides/source/action_controller_overview.md
+++ b/guides/source/action_controller_overview.md
@@ -193,7 +193,7 @@ In a given request, the method is not actually called for every single generated
 
 With strong parameters, Action Controller parameters are forbidden to
 be used in Active Model mass assignments until they have been
-whitelisted. This means that you'll have to make a conscious decision about
+allowlisted. This means that you'll have to make a conscious decision about
 which attributes to allow for mass update. This is a better security
 practice to help prevent accidentally allowing users to update sensitive
 model attributes.
@@ -241,7 +241,7 @@ Given
 params.permit(:id)
 ```
 
-the key `:id` will pass the whitelisting if it appears in `params` and
+the key `:id` will pass the allowlisting if it appears in `params` and
 it has a permitted scalar value associated. Otherwise, the key is going
 to be filtered out, so arrays, hashes, or any other objects cannot be
 injected.
@@ -269,7 +269,7 @@ but be careful because this opens the door to arbitrary input. In this
 case, `permit` ensures values in the returned structure are permitted
 scalars and filters out anything else.
 
-To whitelist an entire hash of parameters, the `permit!` method can be
+To allowlist an entire hash of parameters, the `permit!` method can be
 used:
 
 ```ruby
@@ -291,7 +291,7 @@ params.permit(:name, { emails: [] },
                          { family: [ :name ], hobbies: [] }])
 ```
 
-This declaration whitelists the `name`, `emails`, and `friends`
+This declaration allowlists the `name`, `emails`, and `friends`
 attributes. It is expected that `emails` will be an array of permitted
 scalar values, and that `friends` will be an array of resources with
 specific attributes: they should have a `name` attribute (any
@@ -326,7 +326,7 @@ parameters when you use `accepts_nested_attributes_for` in combination
 with a `has_many` association:
 
 ```ruby
-# To whitelist the following data:
+# To allowlist the following data:
 # {"book" => {"title" => "Some Book",
 #             "chapters_attributes" => { "1" => {"title" => "First Chapter"},
 #                                        "2" => {"title" => "Second Chapter"}}}}
@@ -336,7 +336,7 @@ params.require(:book).permit(:title, chapters_attributes: [:title])
 
 Imagine a scenario where you have parameters representing a product
 name and a hash of arbitrary data associated with that product, and
-you want to whitelist the product name attribute and also the whole
+you want to allowlist the product name attribute and also the whole
 data hash:
 
 ```ruby
@@ -349,7 +349,7 @@ end
 
 The strong parameter API was designed with the most common use cases
 in mind. It is not meant as a silver bullet to handle all of your
-whitelisting problems. However, you can easily mix the API with your
+allowlisting problems. However, you can easily mix the API with your
 own code to adapt to your situation.
 
 Session
diff --git a/guides/source/configuring.md b/guides/source/configuring.md
index 6e4f1f9648..dfeb1f27ec 100644
--- a/guides/source/configuring.md
+++ b/guides/source/configuring.md
@@ -275,7 +275,7 @@ config.middleware.delete Rack::MethodOverride
 
 All these configuration options are delegated to the `I18n` library.
 
-* `config.i18n.available_locales` whitelists the available locales for the app. Defaults to all locale keys found in locale files, usually only `:en` on a new application.
+* `config.i18n.available_locales` allowlists the available locales for the app. Defaults to all locale keys found in locale files, usually only `:en` on a new application.
 
 * `config.i18n.default_locale` sets the default locale of an application used for i18n. Defaults to `:en`.
 
@@ -444,7 +444,7 @@ The schema dumper adds two additional configuration options:
 
 * `config.action_controller.action_on_unpermitted_parameters` enables logging or raising an exception if parameters that are not explicitly permitted are found. Set to `:log` or `:raise` to enable. The default value is `:log` in development and test environments, and `false` in all other environments.
 
-* `config.action_controller.always_permitted_parameters` sets a list of whitelisted parameters that are permitted by default. The default values are `['controller', 'action']`.
+* `config.action_controller.always_permitted_parameters` sets a list of allowlisted parameters that are permitted by default. The default values are `['controller', 'action']`.
 
 * `config.action_controller.enable_fragment_cache_logging` determines whether to log fragment cache reads and writes in verbose format as follows:
 
diff --git a/guides/source/debugging_rails_applications.md b/guides/source/debugging_rails_applications.md
index 88d205e1ab..902b9797df 100644
--- a/guides/source/debugging_rails_applications.md
+++ b/guides/source/debugging_rails_applications.md
@@ -888,7 +888,7 @@ do that with `local_variables`.
 
 ### Settings
 
-* `config.web_console.whitelisted_ips`: Authorized list of IPv4 or IPv6
+* `config.web_console.allowlisted_ips`: Authorized list of IPv4 or IPv6
 addresses and networks (defaults: `127.0.0.1/8, ::1`).
 * `config.web_console.whiny_requests`: Log a message when a console rendering
 is prevented (defaults: `true`).
diff --git a/guides/source/form_helpers.md b/guides/source/form_helpers.md
index a4f7e6f601..86d0e6b18b 100644
--- a/guides/source/form_helpers.md
+++ b/guides/source/form_helpers.md
@@ -953,7 +953,7 @@ If the associated object is already saved, `fields_for` autogenerates a hidden i
 ### The Controller
 
 As usual you need to
-[whitelist the parameters](action_controller_overview.html#strong-parameters) in
+[allowlist the parameters](action_controller_overview.html#strong-parameters) in
 the controller before you pass them to the model:
 
 ```ruby
@@ -999,7 +999,7 @@ remove addresses:
 <% end %>
 ```
 
-Don't forget to update the whitelisted params in your controller to also include
+Don't forget to update the allowlisted params in your controller to also include
 the `_destroy` field:
 
 ```ruby
diff --git a/guides/source/getting_started.md b/guides/source/getting_started.md
index 88a13cdd70..a0dbc3de7d 100644
--- a/guides/source/getting_started.md
+++ b/guides/source/getting_started.md
@@ -779,7 +779,7 @@ extra fields with values that violated your application's integrity? They would
 be 'mass assigned' into your model and then into the database along with the
 good stuff - potentially breaking your application or worse.
 
-We have to whitelist our controller parameters to prevent wrongful mass
+We have to allowlist our controller parameters to prevent wrongful mass
 assignment. In this case, we want to both allow and require the `title` and
 `text` parameters for valid use of `create`. The syntax for this introduces
 `require` and `permit`. The change will involve one line in the `create` action:
diff --git a/guides/source/i18n.md b/guides/source/i18n.md
index 7843df5b18..6437d45052 100644
--- a/guides/source/i18n.md
+++ b/guides/source/i18n.md
@@ -77,8 +77,8 @@ There are also attribute readers and writers for the following attributes:
 load_path                 # Announce your custom translation files
 locale                    # Get and set the current locale
 default_locale            # Get and set the default locale
-available_locales         # Whitelist locales available for the application
-enforce_available_locales # Enforce locale whitelisting (true or false)
+available_locales         # Allowlist locales available for the application
+enforce_available_locales # Enforce locale allowlisting (true or false)
 exception_handler         # Use a different exception_handler
 backend                   # Use a different backend
 ```
@@ -128,7 +128,7 @@ The load path must be specified before any translations are looked up. To change
 # Where the I18n library should search for translation files
 I18n.load_path += Dir[Rails.root.join('lib', 'locale', '*.{rb,yml}')]
 
-# Whitelist locales available for the application
+# Allowlist locales available for the application
 I18n.available_locales = [:en, :pt]
 
 # Set default locale to something other than :en
diff --git a/guides/source/routing.md b/guides/source/routing.md
index 8c69e2600b..54d04dd0d6 100644
--- a/guides/source/routing.md
+++ b/guides/source/routing.md
@@ -719,12 +719,12 @@ NOTE: There is an exception for the `format` constraint: while it's a method on
 
 ### Advanced Constraints
 
-If you have a more advanced constraint, you can provide an object that responds to `matches?` that Rails should use. Let's say you wanted to route all users on a blacklist to the `BlacklistController`. You could do:
+If you have a more advanced constraint, you can provide an object that responds to `matches?` that Rails should use. Let's say you wanted to route all users on a denylist to the `DenylistController`. You could do:
 
 ```ruby
-class BlacklistConstraint
+class DenylistConstraint
   def initialize
-    @ips = Blacklist.retrieve_ips
+    @ips = Denylist.retrieve_ips
   end
 
   def matches?(request)
@@ -733,8 +733,8 @@ class BlacklistConstraint
 end
 
 Rails.application.routes.draw do
-  get '*path', to: 'blacklist#index',
-    constraints: BlacklistConstraint.new
+  get '*path', to: 'denylist#index',
+    constraints: DenylistConstraint.new
 end
 ```
 
@@ -742,8 +742,8 @@ You can also specify constraints as a lambda:
 
 ```ruby
 Rails.application.routes.draw do
-  get '*path', to: 'blacklist#index',
-    constraints: lambda { |request| Blacklist.retrieve_ips.include?(request.remote_ip) }
+  get '*path', to: 'denylist#index',
+    constraints: lambda { |request| Denylist.retrieve_ips.include?(request.remote_ip) }
 end
 ```
 
diff --git a/guides/source/security.md b/guides/source/security.md
index 9fbd252bb7..9be304ecb9 100644
--- a/guides/source/security.md
+++ b/guides/source/security.md
@@ -378,7 +378,7 @@ This will redirect the user to the main action if they tried to access a legacy
 http://www.example.com/site/legacy?param1=xy&param2=23&host=www.attacker.com
 ```
 
-If it is at the end of the URL it will hardly be noticed and redirects the user to the attacker.com host. A simple countermeasure would be to _include only the expected parameters in a legacy action_ (again a whitelist approach, as opposed to removing unexpected parameters). _And if you redirect to a URL, check it with a whitelist or a regular expression_.
+If it is at the end of the URL it will hardly be noticed and redirects the user to the attacker.com host. A simple countermeasure would be to _include only the expected parameters in a legacy action_ (again a allowlist approach, as opposed to removing unexpected parameters). _And if you redirect to a URL, check it with a allowlist or a regular expression_.
 
 #### Self-contained XSS
 
@@ -394,7 +394,7 @@ NOTE: _Make sure file uploads don't overwrite important files, and process media
 
 Many web applications allow users to upload files. _File names, which the user may choose (partly), should always be filtered_ as an attacker could use a malicious file name to overwrite any file on the server. If you store file uploads at /var/www/uploads, and the user enters a file name like "../../../etc/passwd", it may overwrite an important file. Of course, the Ruby interpreter would need the appropriate permissions to do so - one more reason to run web servers, database servers, and other programs as a less privileged Unix user.
 
-When filtering user input file names, _don't try to remove malicious parts_. Think of a situation where the web application removes all "../" in a file name and an attacker uses a string such as "....//" - the result will be "../". It is best to use a whitelist approach, which _checks for the validity of a file name with a set of accepted characters_. This is opposed to a blacklist approach which attempts to remove not allowed characters. In case it isn't a valid file name, reject it (or replace not accepted characters), but don't remove them. Here is the file name sanitizer from the [attachment_fu plugin](https://github.com/technoweenie/attachment_fu/tree/master):
+When filtering user input file names, _don't try to remove malicious parts_. Think of a situation where the web application removes all "../" in a file name and an attacker uses a string such as "....//" - the result will be "../". It is best to use a allowlist approach, which _checks for the validity of a file name with a set of accepted characters_. This is opposed to a denylist approach which attempts to remove not allowed characters. In case it isn't a valid file name, reject it (or replace not accepted characters), but don't remove them. Here is the file name sanitizer from the [attachment_fu plugin](https://github.com/technoweenie/attachment_fu/tree/master):
 
 ```ruby
 def sanitize_filename(filename)
@@ -641,19 +641,19 @@ INFO: _Injection is a class of attacks that introduce malicious code or paramete
 
 Injection is very tricky, because the same code or parameter can be malicious in one context, but totally harmless in another. A context can be a scripting, query, or programming language, the shell, or a Ruby/Rails method. The following sections will cover all important contexts where injection attacks may happen. The first section, however, covers an architectural decision in connection with Injection.
 
-### Whitelists versus Blacklists
+### Allowlists versus Denylists
 
-NOTE: _When sanitizing, protecting, or verifying something, prefer whitelists over blacklists._
+NOTE: _When sanitizing, protecting, or verifying something, prefer allowlists over denylists._
 
-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_:
+A denylist can be a list of bad e-mail addresses, non-public actions or bad HTML tags. This is opposed to a allowlist which lists the good e-mail addresses, public actions, good HTML tags, and so on. Although sometimes it is not possible to create a allowlist (in a SPAM filter, for example), _prefer to use allowlist approaches_:
 
 * Use before_action except: [...] instead of only: [...] for security-related actions. This way you don't forget to enable security checks for newly added actions.
 * Allow &lt;strong&gt; instead of removing &lt;script&gt; against Cross-Site Scripting (XSS). See below for details.
-* Don't try to correct user input by blacklists:
+* Don't try to correct user input by denylists:
     * This will make the attack work: "&lt;sc&lt;script&gt;ript&gt;".gsub("&lt;script&gt;", "")
     * But reject malformed input
 
-Whitelists are also a good approach against the human factor of forgetting something in the blacklist.
+Allowlists are also a good approach against the human factor of forgetting something in the denylist.
 
 ### SQL Injection
 
@@ -810,15 +810,15 @@ http://www.cbsnews.com/stories/2002/02/15/weather_local/main501644.shtml?zipcode
 
 _It is very important to filter malicious input, but it is also important to escape the output of the web application_.
 
-Especially for XSS, it is important to do _whitelist input filtering instead of blacklist_. Whitelist filtering states the values allowed as opposed to the values not allowed. Blacklists are never complete.
+Especially for XSS, it is important to do _allowlist input filtering instead of denylist_. Allowlist filtering states the values allowed as opposed to the values not allowed. Denylists are never complete.
 
-Imagine a blacklist deletes "script" from the user input. Now the attacker injects "&lt;scrscriptipt&gt;", and after the filter, "&lt;script&gt;" remains. Earlier versions of Rails used a blacklist approach for the strip_tags(), strip_links() and sanitize() method. So this kind of injection was possible:
+Imagine a denylist deletes "script" from the user input. Now the attacker injects "&lt;scrscriptipt&gt;", and after the filter, "&lt;script&gt;" remains. Earlier versions of Rails used a denylist approach for the strip_tags(), strip_links() and sanitize() method. So this kind of injection was possible:
 
 ```ruby
 strip_tags("some<<b>script>alert('hello')<</b>/script>")
 ```
 
-This returned "some&lt;script&gt;alert('hello')&lt;/script&gt;", which makes an attack work. That's why a whitelist approach is better, using the updated Rails 2 method sanitize():
+This returned "some&lt;script&gt;alert('hello')&lt;/script&gt;", which makes an attack work. That's why a allowlist approach is better, using the updated Rails 2 method sanitize():
 
 ```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)
@@ -852,7 +852,7 @@ The following is an excerpt from the [Js.Yamanner@m](http://www.symantec.com/sec
   var IDList = '';   var CRumb = '';   function makeRequest(url, Func, Method,Param) { ...
 ```
 
-The worms exploit a hole in Yahoo's HTML/JavaScript filter, which usually filters all targets and onload attributes from tags (because there can be JavaScript). The filter is applied only once, however, so the onload attribute with the worm code stays in place. This is a good example why blacklist filters are never complete and why it is hard to allow HTML/JavaScript in a web application.
+The worms exploit a hole in Yahoo's HTML/JavaScript filter, which usually filters all targets and onload attributes from tags (because there can be JavaScript). The filter is applied only once, however, so the onload attribute with the worm code stays in place. This is a good example why denylist filters are never complete and why it is hard to allow HTML/JavaScript in a web application.
 
 Another proof-of-concept webmail worm is Nduja, a cross-domain worm for four Italian webmail services. Find more details on [Rosario Valotta's paper](http://www.xssed.com/news/37/Nduja_Connection_A_cross_webmail_worm_XWW/). Both webmail worms have the goal to harvest email addresses, something a criminal hacker could make money with.
 
@@ -876,7 +876,7 @@ So the payload is in the style attribute. But there are no quotes allowed in the
 <div id="mycode" expr="alert('hah!')" style="background:url('javascript:eval(document.all.mycode.expr)')">
 ```
 
-The eval() function is a nightmare for blacklist input filters, as it allows the style attribute to hide the word "innerHTML":
+The eval() function is a nightmare for denylist input filters, as it allows the style attribute to hide the word "innerHTML":
 
 ```
 alert(eval('document.body.inne' + 'rHTML'));
@@ -896,7 +896,7 @@ The [moz-binding](http://www.securiteam.com/securitynews/5LP051FHPE.html) CSS pr
 
 #### Countermeasures
 
-This example, again, showed that a blacklist filter is never complete. However, as custom CSS in web applications is a quite rare feature, it may be hard to find a good whitelist CSS filter. _If you want to allow custom colors or images, you can allow the user to choose them and build the CSS in the web application_. Use Rails' `sanitize()` method as a model for a whitelist CSS filter, if you really need one.
+This example, again, showed that a denylist filter is never complete. However, as custom CSS in web applications is a quite rare feature, it may be hard to find a good allowlist CSS filter. _If you want to allow custom colors or images, you can allow the user to choose them and build the CSS in the web application_. Use Rails' `sanitize()` method as a model for a allowlist CSS filter, if you really need one.
 
 ### Textile Injection
 
@@ -925,7 +925,7 @@ RedCloth.new("<a href='javascript:alert(1)'>hello</a>", [:filter_html]).to_html
 
 #### Countermeasures
 
-It is recommended to _use RedCloth in combination with a whitelist input filter_, as described in the countermeasures against XSS section.
+It is recommended to _use RedCloth in combination with a allowlist input filter_, as described in the countermeasures against XSS section.
 
 ### Ajax Injection
 
diff --git a/guides/source/upgrading_ruby_on_rails.md b/guides/source/upgrading_ruby_on_rails.md
index 319bc09be3..734c7cb5ce 100644
--- a/guides/source/upgrading_ruby_on_rails.md
+++ b/guides/source/upgrading_ruby_on_rails.md
@@ -1200,7 +1200,7 @@ to the database as `NULL` instead of passing the `nil` value through YAML (`"---
 * Rails 4.0 has removed `attr_accessible` and `attr_protected` feature in favor of Strong Parameters. You can use the [Protected Attributes gem](https://github.com/rails/protected_attributes) for a smooth upgrade path.
 
 * If you are not using Protected Attributes, you can remove any options related to
-this gem such as `whitelist_attributes` or `mass_assignment_sanitizer` options.
+this gem such as `allowlist_attributes` or `mass_assignment_sanitizer` options.
 
 * Rails 4.0 requires that scopes use a callable object such as a Proc or lambda: