Rails API × hashid-rails：外部公開APIで安全にIDを扱う方法

はじめに

なぜAPIでそのまま数値IDを公開すると良くないのか？

• 推測可能（/users/1, /users/2 → 他人の情報が見えるリスク）
• クローラーや攻撃者に総当たりされやすいです。
  そこで「IDをそのまま出さずに安全に扱う仕組み」が必要になります。

hashid-railsとは？

hashids ライブラリをRailsで使いやすくしたGemです。

• 数値IDを 短くて一意な文字列 に変換します。
  例: 12345 → jR
• 双方向変換可能（ハッシュから元のIDに復元できる）です。
• UUIDと違い、既存の整数IDを隠す用途に便利です。

セットアップ

• Gemfile に追加

ruby

gem 'hashid-rails'

• インストール & 設定ファイル生成します。

bundle install
rails generate hashid:rails install

config/initializers/hashid.rb でカスタマイズ可能（salt, min_length など）

モデルでの利用方法

モデルに hashid-rails を組み込む方法です。

user.rb

class User < ApplicationRecord
  include Hashid::Rails
end

これで user.hashid が利用可能になります。

ruby

## 例: 
User.find(1).hashid # => "jR"

APIレスポンスでの使い方

コントローラーでIDをそのまま返さず hashid を返します。

ruby

def show
  user = User.find(params[:id])
  render json: { id: user.hashid, name: user.name }
end

以下の形でhashされたidが返ってきます。

json

{
  "id": "jR",
  "name": "Alice"
}

リクエストパラメータでの利用

APIを叩くときは「hashid」をリクエストに使います。

http

GET /api/users/jR

ruby

def show
  user = User.find_by_hashid(params[:id])
  render json: user
end

他のhashする方法との比較

• 数値ID（そのまま） → 推測されやすく完璧的なセキュリティ対策ではないです。
• UUID → 衝突リスクなし・安全性高いが、長くて扱いにくいかもです。
• hashid-rails → 見た目も短く、既存の整数IDを隠せます。
  👉 「セキュリティ」＋「開発しやすさ」のバランスが良いのがhashid-railsです。

注意点

• 完全なセキュリティ対策ではないです。（総当たりは可能）
• 認可（Authorization）の仕組みは別途必要です。
• 公開APIでIDを隠す「補助的な手段」と理解すべきです。

まとめ

• APIで数値IDを公開するとリスクがあります。
• hashid-railsを使うと 短く安全にIDを扱えます。
• UUIDやトークン認証と組み合わせるとさらに強固になります。