docs/guide-ja/security reviewed [ci skip]

docs/guide-ja/security-auth-clients.md

@@ -65,7 +65,7 @@ OpenID では、たいていの場合、何も設定しなくても動作しま
 外部サービスによって認証されたユーザを認識するために、最初の認証のときに提供された ID を保存し、以後の認証のときにはそれをチェックする必要があります。
 ログインのオプションを外部サービスに限定するのは良いアイデアではありません。
 外部サービスによる認証が失敗して、ユーザがログインする方法がなくなるかもしれないからです。
-そんなことはせずに、外部認証と昔ながらのパスワードによるログインの両方を提供する方が良いです。
+そんなことはせずに、外部認証と昔ながらのパスワードによるログインの両方を提供する方が適切です。
 
 ユーザの情報をデータベースに保存しようとする場合、スキーマは次のようなものになります。
 

docs/guide-ja/security-authentication.md

@@ -20,10 +20,10 @@ class User extends ActiveRecord implements IdentityInterface
     // ...
 
     /**
-     * 与えられた ID によって識別子を探す
+     * 与えられた ID によってユーザ識別情報を探す
      *
      * @param string|integer $id 探すための ID
-     * @return IdentityInterface|null 与えられた ID に合致する識別子オブジェクト
+     * @return IdentityInterface|null 与えられた ID に合致する Identity オブジェクト
      */
     public static function findIdentity($id)
     {
@@ -31,10 +31,10 @@ class User extends ActiveRecord implements IdentityInterface
     }
 
     /**
-     * 与えられたトークンによって識別子を探す
+     * 与えられたトークンによってユーザ識別情報を探す
      *
      * @param string $token 探すためのトークン
-     * @return IdentityInterface|null 与えられたトークンに合致する識別子オブジェクト
+     * @return IdentityInterface|null 与えられたトークンに合致する Identity オブジェクト
      */
     public static function findIdentityByAccessToken($token, $type = null)
     {
@@ -74,7 +74,7 @@ class User extends ActiveRecord implements IdentityInterface
 その他のメソッドのうち、二つのもの - `getAuthKey` と `validateAuthKey` - は、「次回から自動ログイン ("remember me")」のクッキーに対して追加のセキュリティを提供するために使われます。
 `getAuthKey` メソッドは全てのユーザに対してユニークな文字列を返さなければなりません。
 `Yii::$app->getSecurity()->generateRandomString()` を使うと、信頼性の高い方法でユニークな文字列を生成することが出来ます。
-これをユーザのレコードの一部として保存しておくのが良いアイデアです。
+これをユーザのレコードの一部として保存しておくのは良いアイデアです。
 
 ```php
 public function beforeSave($insert)

docs/guide-ja/security-authorization.md

@@ -3,7 +3,7 @@
 
 > Note|注意: この節はまだ執筆中です。
 
-権限付与は、ユーザが何かをするのに十分な許可を得ているか否かを確認するプロセスです。
+権限付与は、ユーザが何かをするのに十分な許可を有しているか否かを確認するプロセスです。
 Yii は二つの権限付与の方法を提供しています。すなわち、アクセス制御フィルタ (ACF) と、ロールベースアクセス制御 (RBAC) です。
 
 
@@ -47,7 +47,7 @@ class SiteController extends Controller
 ```
 
 上記のコードにおいて、ACF は `site` コントローラにビヘイビアとしてアタッチされています。
-これはアクションフィルタを使用する典型的な方法です。
+これがアクションフィルタを使用する典型的な方法です。
 `only` オプションは、ACF が `login`、`logout`、`signup` のアクションにのみ適用されるべきであることを指定しています。
 `rules` オプションは [[yii\filters\AccessRule|アクセス規則]] を指定するものであり、以下のように読むことが出来ます。
 
@@ -172,7 +172,7 @@ RBAC を使用することには、二つの作業が含まれます。
 一つのロールを一人または複数のユーザに割り当てることが出来ます。
 ユーザが特定の許可を有しているか否かをチェックするためには、その許可を含むロールがユーザに割り当てられているか否かをチェックすればよいのです。
 
-各ロールまたは許可に関連付けられた *規則* が存在することがあり得ます。
+各ロールまたは許可に関連付けられた *規則* が存在し得ます。
 規則とは、アクセスチェックの際に、対応するロールや許可が現在のユーザに適用されるか否かを決定するために実行されるコード断片のことです。
 例えば、「記事更新」の許可は、現在のユーザが記事の作成者であるかどうかをチェックする規則を持つことが出来ます。
 そして、アクセスチェックのときに、ユーザが記事の作成者でない場合は、彼/彼女は「記事更新」の許可を持っていないと見なすことが出来ます。
@@ -293,7 +293,7 @@ class RbacController extends Controller
         $auth->addChild($admin, $author);
 
         // ロールをユーザに割り当てる。1 と 2 は IdentityInterface::getId() によって返される ID
-        // 通常はユーザモデルの中で実装する
+        // IdentityInterface::getId() は、通常は User モデルの中で実装される
         $auth->assign($author, 2);
         $auth->assign($admin, 1);
     }
@@ -306,7 +306,7 @@ class RbacController extends Controller
 
 投稿者 (author) は記事を投稿することが出来、管理者 (admin) は記事を更新することに加えて投稿者が出来る全てのことが出来ます。
 
-あなたのアプリケーションがユーザ登録を許している場合は、新しく登録されたユーザに一度ロールを割り当てる必要があります。
+あなたのアプリケーションがユーザ自身によるユーザ登録を許している場合は、新しく登録されたユーザに一度はロールを割り当てる必要があります。
 例えば、アドバンストアプリケーションテンプレートにおいては、登録したユーザの全てを「投稿者」にするために、`frontend\models\SignupForm::signup()` を次のように修正しなければなりません。
 
 ```php
@@ -339,7 +339,7 @@ public function signup()
 
 既に述べたように、規則がロールと許可に制約を追加します。
 規則は [[yii\rbac\Rule]] を拡張したクラスであり、[[yii\rbac\Rule::execute()|execute()]] メソッドを実装しなければなりません。
-前に作った権限階層においては、投稿者は自分自身の記事を編集することが出来ないものでした。これを修正しましょう。
+前に作った権限階層においては、投稿者は自分自身の記事を編集することが出来ませんでした。これを修正しましょう。
 最初に、ユーザが記事の投稿者であることを確認する規則が必要です。
 
 ```php
@@ -512,4 +512,4 @@ return [
 
 このようにすると、アクセスチェックを実行すると、`admin` と `author` の両方のロールは、それらと関連付けられた規則を評価することによってチェックされるようになります。
 規則が true を返せば、そのロールが現在のユーザに適用されることになります。
-上述の規則の実装に基づいて言えば、ユーザの `group` の値が 1 であれば、`admin` ロールがユーザに適用され、`group` の値が 2 であれば `author` ロールが適用されるということを意味します。
+上述の規則の実装に基づいて言えば、ユーザの `group` の値が 1 であれば `admin` ロールがユーザに適用され、`group` の値が 2 であれば `author` ロールが適用されるということを意味します。

docs/guide-ja/security-best-practices.md

@@ -15,13 +15,13 @@
 ### 入力をフィルタする
 
 入力をフィルタするとは、入力値は決して安全なものであると見なさず、取得した値が実際に許可さていれる値に含まれるか否かを常にチェックしなければならない、ということを意味します。
-つまり、並べ替えが三つのフィールド `title`、`created_at` および `status` によって実行され、フィールドの値がインプットによって提供されるものであることを知っている場合、取得した値を受信するその場でチェックする方が良い、ということです。
+例えば、並べ替えが三つのフィールド `title`、`created_at` および `status` によって実行され、フィールドの名前がユーザの入力によって提供されるものであることを知っている場合、取得した値を受信するその場でチェックする方が良い、ということです。
 基本的な PHP の形式では、次のようなコードになります。
 
 ```php
 $sortBy = $_GET['sort'];
 if (!in_array($sortBy, ['title', 'created_at', 'status'])) {
-	throw new Exception('Invalid sort value.');
+	throw new Exception('sort の値が不正です。');
 }
 ```
 
@@ -83,7 +83,7 @@ $userIDs = $connection
 function actionList($orderBy = null)
 {
     if (!in_array($orderBy, ['name', 'status'])) {
-        throw new BadRequestHttpException('名前とステータスだけを並べ替えに使うことが出来ます。')
+        throw new BadRequestHttpException('name と status だけを並べ替えに使うことが出来ます。')
     }
     
     // ...

docs/guide-ja/security-passwords.md

@@ -3,21 +3,21 @@
 
 > Note|注意: この節はまだ執筆中です。
 
-十分なセキュリティは、どのようなアプリケーションであっても、健全さを保って成功するためには欠くことが出来ないものです。
+十分なセキュリティは、すべてのアプリケーションの健全さと成功のために欠くことが出来ないものです。
 不幸なことに、理解が不足しているためか、実装の難易度が高すぎるためか、セキュリティのことになると手を抜く開発者がたくさんいます。
-Yii によって駆動されるアプリケーションを可能な限り安全にするために、Yii はいくつかの優秀な使いやすいセキュリティ機能を内蔵しています。
+Yii によって駆動されるあなたのアプリケーションを可能な限り安全にするために、Yii はいくつかの優秀な使いやすいセキュリティ機能を内蔵しています。
 
 
 ハッシュとパスワードの検証
 --------------------------
 
-ほとんどの開発者はパスワードを平文テキストでは保存できないということを知っていますが、パスワードを `md5` や `sha1` でハッシュしてもまだ安全だと思っている開発者がたくさんいます。
+ほとんどの開発者はパスワードを平文テキストで保存してはいけないということを知っていますが、パスワードを `md5` や `sha1` でハッシュしてもまだ安全だと思っている開発者がたくさんいます。
 かつては、前述のハッシュアルゴリズムを使えば十分であった時もありましたが、現代のハードウェアをもってすれば、そのようなハッシュはブルートフォースアタックを使って非常に簡単に復元することが可能です。
 
 最悪のシナリオ (アプリケーションに侵入された場合) であっても、ユーザのパスワードについて強化されたセキュリティを提供することが出来るように、ブルートフォースアタックに対する耐性が強いハッシュアルゴリズムを使う必要があります。
 現在、最善の選択は `bcrypt` です。
 PHP では、[crypt 関数](http://php.net/manual/ja/function.crypt.php) を使って `bcrypt` ハッシュを生成することが出来ます。
-Yii は `crypt` を使ってハッシュを安全に生成し検証することを容易にする二つのヘルパ関数を提供します。
+Yii は `crypt` を使ってハッシュを安全に生成し検証することを容易にするために、二つのヘルパ関数を提供しています。
 
 ユーザが初めてパスワードを提供するとき (例えば、ユーザ登録の時) には、パスワードをハッシュする必要があります。
 
@@ -28,7 +28,7 @@ $hash = Yii::$app->getSecurity()->generatePasswordHash($password);
 
 そして、ハッシュを対応するモデル属性と関連付けて、後で使用するためにデータベースに保存します。
 
-ユーザがログインを試みたときは、送信されたパスワードは、前にハッシュされて保存されたパスワードと照合して検証されます。
+ユーザがログインを試みたときは、送信されたパスワードは、前にハッシュされて保存されたパスワードと照合して検証されなければなりません。
 
 
 ```php