Laravel 8で foreignIdFor() メソッドが導入されました。
外部キーカラムの定義がよりシンプルで安全になる機能です。

foreignIdFor() とは

foreignIdFor() は、モデルクラスから外部キーカラムを自動生成するメソッドです。

Before: 従来の書き方

$table->unsignedBigInteger('user_id');
$table->foreign('user_id')
    ->references('id')
    ->on('users')
    ->onDelete('cascade');

After: foreignIdFor() を使った書き方

$table->foreignIdFor(User::class)
    ->constrained()
    ->onDelete('cascade');

わずか1行で、カラムの作成から外部キー制約の設定まで完結します。

constrained() メソッドについて

constrained() は外部キー制約を自動的に設定するメソッドです。

$table->foreignIdFor(User::class)->constrained();

このコードは以下を自動的に行います:
– モデルクラスから参照先のテーブル名を推測（User → users）
– 主キーカラム id への参照を作成
– 外部キー制約を設定

constrained() を呼ばなければ、カラムのみが作成され、外部キー制約は設定されません。

// カラムのみ作成（制約なし）
$table->foreignIdFor(User::class);

// カラム + インデックスのみ（制約なし）
$table->foreignIdFor(User::class)->index();

主なメリット

1. 型の安全性が向上

参照先のテーブルの主キー型と自動的に一致します。
users.id が bigInteger なら、外部キーも unsignedBigInteger として作成されます。

2. タイプミスを防止

// モデルクラスから自動生成されるため、タイプミスが起きない
$table->foreignIdFor(User::class); // → user_id

// 従来の方法だとタイプミスのリスク
$table->unsignedBigInteger('usr_id'); // うっかりミス

3. コードの意図が明確

一目で「これは User モデルへの外部キーだ」と分かります。

注意点

モデルクラスが必要

当然ですが、モデルクラスが存在しないと使えません。

// モデルがない外部サービスのテーブルなど
$table->unsignedBigInteger('external_service_id');

カスタムテーブル名に注意

モデル名とテーブル名が規則通りでない場合は、明示的に指定が必要です。

class Person extends Model {
    protected $table = 'users';
}

// persons テーブルを探してしまうため、明示的に指定
$table->foreignIdFor(Person::class)->constrained('users');

カラム名のカスタマイズ

デフォルトでは {model}_id という名前になります。
カスタマイズする場合は第2引数を使います。

$table->foreignIdFor(User::class, 'author_id')->constrained('users');

複合主キーには非対応

複合主キーへの参照には従来の方法を使う必要があります。

よく使うパターン

// nullable な外部キー
$table->foreignIdFor(User::class)->nullable()->constrained();

// カスケード削除
$table->foreignIdFor(User::class)
    ->constrained()
    ->onDelete('cascade');

// SET NULL
$table->foreignIdFor(User::class)
    ->nullable()
    ->constrained()
    ->onDelete('set null');

// インデックスのみ（外部キー制約なし）
$table->foreignIdFor(User::class)->index();

まとめ

foreignIdFor() は、外部キー定義をより安全で保守しやすくする優れた機能です。
特別な理由がない限り、Laravel 8以降のプロジェクトでは積極的に使用することをお勧めします。

はじめに

APIエンドポイント /api/projects/{id} において、認証（Authentication）は通っているものの、認可（Authorization）の検証が不十分なケースがあります。

例えば、ユーザーAが自身のトークンを用いて、ユーザーBが所有する project_id を指定して GET / PUT / DELETE リクエストを送信した場合、サーバー側で所有権をチェックしていなければ、他人のデータを閲覧・改ざんできてしまいます。

これは典型的な IDOR (Insecure Direct Object Reference) 脆弱性です。

// 脆弱な例
public function update(Request $request, Project $project)
{
    // ログインしていることは確認されているが、
    // $project がログインユーザーのものかは見ていない
    $project->update($request->all());
}

Policyとは

Laravel Policyは、特定のモデルに対する認可ロジックをひとつのクラスに集約する仕組みです。

コントローラーやミドルウェアに if ($project->user_id !== auth()->id()) のようなチェックを散在させる代わりに、Policyクラスに認可ルールを定義し、コントローラーから呼び出します。

これにより以下のメリットが得られます。

• 認可ロジックの一元管理 ─ 変更時にコントローラーを探し回る必要がありません
• テストの容易さ ─ Policyクラス単体でユニットテストが書けます
• 一貫性 ─ authorize メソッドやミドルウェアを通じて、どのエンドポイントでも同じルールが適用されます

Policyで解決する

1. Policyの生成

php artisan make:policy ProjectPolicy --model=Project

2. 認可ロジックの定義

app/Policies/ProjectPolicy.php に各アクションの認可ルールを記述します。

<?php

namespace App\Policies;

use App\Models\Project;
use App\Models\User;

class ProjectPolicy
{
    /**
     * プロジェクトの閲覧権限
     */
    public function view(User $user, Project $project): bool
    {
        return $user->id === $project->user_id;
    }

    /**
     * プロジェクトの更新権限
     */
    public function update(User $user, Project $project): bool
    {
        return $user->id === $project->user_id;
    }

    /**
     * プロジェクトの削除権限
     */
    public function delete(User $user, Project $project): bool
    {
        return $user->id === $project->user_id;
    }
}

ロジックはシンプルで、プロジェクトの user_id とログインユーザーの id が一致するかどうかだけを返します。

false が返れば、Laravelは自動的に 403 Forbidden レスポンスを返します。

3. Policyの登録

Laravel 8以降では、Policyの自動検出が有効です。
App\Models\Project に対して App\Policies\ProjectPolicy という命名規則に従っていれば、手動登録は不要です。

Laravel 10以前では AuthServiceProvider で明示的に登録することも可能です。
なお、Laravel 11以降では AuthServiceProvider がデフォルトのスケルトンから削除されているため、命名規則に従わない場合は AppServiceProvider の boot メソッド内で Gate::policy() を使って登録してください。

// Laravel 10以前: AuthServiceProvider
protected $policies = [
    Project::class => ProjectPolicy::class,
];

// Laravel 11以降: AppServiceProvider（命名規則に従わない場合）
use Illuminate\Support\Facades\Gate;

public function boot(): void
{
    Gate::policy(Project::class, ProjectPolicy::class);
}

4. コントローラーでの適用

コントローラーの各メソッドで $this->authorize() を呼ぶだけで適用できます。

class ProjectController extends Controller
{
    public function show(Project $project)
    {
        $this->authorize('view', $project);

        return ProjectResource::make($project);
    }

    public function update(Request $request, Project $project)
    {
        $this->authorize('update', $project);

        $project->update($request->validated());

        return ProjectResource::make($project);
    }

    public function destroy(Project $project)
    {
        $this->authorize('delete', $project);

        $project->delete();

        return response()->noContent();
    }
}

これで、ユーザーAがユーザーBのプロジェクトIDを指定した場合、403 Forbidden が返却されます。

補足: authorizeResourceを使う方法

リソースコントローラーであれば、コンストラクタで一括適用もできます。

class ProjectController extends Controller
{
    public function __construct()
    {
        $this->authorizeResource(Project::class, 'project');
    }

    // 各メソッドからauthorize()の呼び出しを削除できます
}

authorizeResource は、コントローラーのメソッド名とPolicyのメソッド名を自動的にマッピングします（show → view、update → update など）。

まとめ

認証（Authentication）はリクエストの送信元が「誰か」を特定するだけであり、「そのリソースへのアクセス権があるか」を判定するのは認可（Authorization）の役割です。
この区別を見落とすと、IDORのような脆弱性が生まれます。

Laravel Policyを使えば、モデルごとの認可ルールを一箇所に集約でき、コントローラーでは $this->authorize() を一行追加するだけで済みます。
まだ導入していない場合は、既存のエンドポイントを一度洗い出して、Policyが適用されているか確認してみてください。