Libraries

役立つ情報ありがとうございます。

リンク先のGitHubのディスカッションを覗いてみたのですが、「poor naming」という表現があり、--safe-methodsというオプション名が紛らわしいということは認識されているみたいですね。
それから、"use the ignore file instead"というポリシーだそうですので、XSSチェック以外のタイプの警告は、1つずつ無視の設定をして欲しいというのがBrakemanの開発側の考えのようですね。

Rails 7.2から新規アプリケーションにおいてBrakemanがデフォルトで有効になりました。 このTopicでは、7.1以前で作成した既存RailsアプリにBrakemanを後から導入して、Brakemanに関して7.2の新規アプリ相当の状態にセットアップする方法をご紹介します。

Brakemanのインストール

まず以下のように、Gemfileのgroup :development, :testのところにbrakemanを追加します。

group :development, :test do

  # Static analysis for security vulnerabilities [https://brakemanscanner.org/]
  gem "brakeman", require: false

end

次にbundle installを実行します。

bundle install

以上でBrakemanのインストールが出来ました。

ローカル環境でのBrakemanの実行

以下のコマンドでBrakemanを実行でき、デフォルトのチェックを行えます。

bundle exec brakeman

全てのチェックを実行する場合には、以下のオプション付けて実行します。

bundle exec brakeman -A

警告の無視に関する設定と管理を行う場合は、以下のオプション付けて実行します。

bundle exec brakeman -I

以下のように、これら2つのオプションを同時に指定して実行することも出来ます。

bundle exec brakeman -IA

なお、Brakemanの詳細については公式ドキュメントをご覧ください。 また、brakemanコマンドのオプションについては日本語訳もあります。

GitHubワークフロー（CI）でのBrakemanの実行

.github/workflows/ci.ymlに相当するファイルがなければ作成します。 この.ymlファイルを編集して、以下のようにjobsの下にscan_rubyジョブを追加します。

ymlファイルの設定に関する注意点

• timeout-minutes:の設定は、実行時間に対して十分余裕を持たせて下さい。
• 「ruby-version: .ruby-version」という設定は、プロジェクトルートにある.ruby-versionという名前のファイルで指定されているrubyのバージョンという意味になります。この設定についての詳細はこちらのTopicをご覧下さい。

jobs:
  scan_ruby:
    runs-on: ubuntu-latest
    timeout-minutes: 10

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: .ruby-version
          bundler-cache: true

      - name: Scan for common Rails security vulnerabilities using static analysis
        run: bundle exec brakeman --no-pager

こちらの公式ドキュメントを読むと、--safe-methodsオプションでメソッド名を指定することで様々なタイプの警告を抑制できるように思えるのですが、このオプションで抑制できるのはXSS (cross-site scripting)チェックのみです。

オプションのマニュアルには「特定のメソッドが適切にエスケープされた値を出力し、そのメソッドがXSSチェックで警告されないようにするためには、次の（--safe-methods）オプションを使います。」と書かれていますし、BrakemanのGitHubのディスカッションでも、「--safe-methods is really only for use with cross-site scripting checks.」という回答が寄せられています。

minitestにおいて、不等号などの二項演算子（例：<, >, <=, =>）を用いたアサーションをしたいときには、 assert_operator()が利用できます。

assert_operator()を用いるメリット

assert_operator()を用いるメリットとして、アサーションが失敗した時の情報が多くなることが挙げられます。

以下のように、assert_operator()を使用した場合は、

x, y = 0, 1
assert_operator x, :>, y

アサーション失敗のメッセージにおいて、以下のように変数の中身も表示してくれます。

Expected 0 to be > 1.

比較して、以下のように単純に記述した場合は、

x, y = 0, 1
assert( x > y )

以下のようにアサーションに失敗した以外の情報を得ることが出来ません。

Expected false to be truthy.

（参考）assert_not_operator

ちなみにrailsのテスト環境では、assert_not_operatorもあります。

Rails 7.1で追加されたパスワード関連エラーメッセージへの対応

has_secure_passwordを利用しているモデルがあり、かつ、英語以外のロケールへ対応している既存アプリでは、 rails 7.1で追加されたエラーの種類であるpassword_too_longに対応するエラーメッセージの訳文を追加する必要があります。 （追加をしないとパスワードが長すぎた場合のエラーメッセージが英語で表示されます。）

なお、本件の詳細についてはこちらをご覧下さい。

Rails 7.1に取り込まれたこちらのプルリクエストによって、 ActiveModel::SecurePasswordのhas_secure_passwordメソッドを利用している場合のパスワードのバリデーションにおいて、 パスワード文字列が72バイト以内かどうかのチェックが行われるようになりました。 そして、72バイトを超えている場合には、password_too_longという新しい種類のエラーが出るようになりました。

この変更に伴って、日本語表示のRailsアプリでは、password_too_longのエラーメッセージの日本語訳を用意する必要があります。 具体的には、以下の階層の所に以下のような日本語訳が必要となります。

ja:
  errors:
    messages:
      password_too_long: が長すぎます

rails 7.2への移行におけるアイコン画像

bin/rails app:updateコマンドを実行すると以下の2つのアイコン画像ファイルがpublic/に作成されますが、
これら2つのファイルは、rails newで生成される新規railsアプリ用のファイルであるため、既存アプリでは単純に削除してしまい、 従来通りのアイコン画像とアイコン設定（faviconやapple-touch-icon）を用いれば大丈夫です。 （もちろん、既存アプリにおいてアイコン設定が適切に行われている場合の話です。）

• icon.png
• icon.svg

ちなみに、以下の通りrails 7.2では、新規アプリのアイコン設定が大幅に更新されています。 rails 7.2のこの新たなアイコン設定は、既存アプリにおいてもアイコン設定を見直す際に役立つかもしません。

（参考）rails 7.2.1の新規アプリのアイコン設定

以下が、新規アプリ用のテンプレートファイルからコピーしたrails 7.2.1の新規アプリのアイコン設定です。

    <link rel="manifest" href="/manifest.json">
    <link rel="icon" href="/icon.png" type="image/png">
    <link rel="icon" href="/icon.svg" type="image/svg+xml">
    <link rel="apple-touch-icon" href="/icon.png">

新たなアイコン画像ファイルによるアイコン設定に関与しているプルリクエストは、 PR #50526と PR #50629です。 3つのアイコン画像ファイル（apple-touch-icon-precomposed.png、apple-touch-icon.png、favicon.ico）が削除され、 2つのアイコン画像ファイル（icon.png、icon.svg）が追加されています。 また、manifestに関しては、PWAに関する新機能に関連して導入されています。

rails 7.2ではassertionがないテストに対して警告が出るようになった

現象

rails 7.2では、Minitestを使ったテストに関して、assert系メソッドが1つも呼ばれないテストがあると"Test is missing assertions"という警告が出るようになりました。

警告が出ないようにする方法

各テストでassert系メソッドが最低1回は実際に呼ばれるようにして下さい。 例外が起きないことを確認するテストではassert_nothing_raisedメソッドを用いて下さい。 なお、警告の回避方法を含め、こちらの記事が参考になるかもしれません。

関連するプルリクエストとコミット

この機能はPR #51625で導入され、このときはrailsアプリの設定によって挙動を変えられるようになっていました。 その後、commit 6a6c7e6によって機能が単純化され、単に常に警告が出力されるだけになりました。 その後、PR #51693で関係するコードを綺麗にする作業などが行われています。

rails 7.2で追加されたブラウザバージョン指定機能と406-unsupported-browser.html

bin/rails app:updateコマンドを実行するとpublic/に406-unsupported-browser.html作成されます。 このHTMLフィアルは、rails 7.2で追加されたブラウザバージョン指定機能が指定範囲外のブラウザに対して送るファイルです。

なお、既存アプリでは、この機能の利用を始めないのであれば、念のため406-unsupported-browser.htmlを置くだけ置いておくという対応で良いように思います。

rails 7.2への移行におけるActive Storageのmigration

bin/rails app:updateコマンドを実行すると以下の3つのファイルがdb/migrate/に作成されることがありますが、
Active Storageをまだ使用したことがないアプリケーションでは、 これら3つのファイルは単純に削除してしまっても良いはずです。

• xxx_add_service_name_to_active_storage_blobs.active_storage.rb
• xxx_create_active_storage_variant_records.active_storage.rb
• xxx_remove_not_null_on_active_storage_blobs_checksum.active_storage.rb

より正確に言うと、データベースにactive_storage_blobsテーブルが存在していない場合は、 これら3つのファイルは単純に削除してしまっても良いはずです。 その理由として、これら3つのファイルはデータベースのactive_storage_blobsテーブルに対して影響を与えるものであり、 table_exists?(:active_storage_blobs)がfalseを返すと何もせずにreturnする処理が3つのファイル全てに記述されているからです。

ご自身のRailsアプリケーションのデータベースにactive_storage_blobsテーブルが存在するかの確認はbin/rails consoleを実行して、 以下のようにコマンドを実行することで行えます。 結果がfalseであればactive_storage_blobsテーブルは存在していない、つまり前述の3つのファイルは削除で大丈夫のはずです。

foobar(dev)> ActiveRecord::Base.connection.table_exists? :active_storage_blobs
=> false

ちなみに、データベースにあるテーブルの一覧を見たい場合にはbin/rails consoleで ActiveRecord::Base.connection.tablesを叩くことでテーブルの一覧を確認できます。