【保存版】Laravelセキュリティ実装大全：CSRF・XSS・認可・Rate Limiting・CSPまで――アクセシブルな安全設計ガイド

この記事で学べること（先に要点）

• CSRF/XSS/SQLインジェクション/マスアサインメントなど、Laravelで押さえるべき主要な脅威と対策コード
• 認証強化（パスワードハッシュ再計算・メール検証・ログイン試行制限・セッション/クッキー設定）と認可の正しい分離
• Rate Limiting・CORS・セキュリティヘッダー（HSTS/Frame-Options/CSP 等）の実務的ミドルウェア実装
• 署名付きURL・暗号化・ファイルアップロード/ダウンロードの安全化・ログのマスキング方法
• 2FA（多要素）導入の勘所とアクセシブルなOTP入力UI、エラーメッセージ設計のコツ
• 「誰も取り残さない」ためのアクセシビリティ配慮（読み上げ・キーボード・色に依存しない状態表示）

想定読者（だれが得をする？）

• Laravel 初〜中級エンジニア：まずはアプリの基本防御を体系的に固めたい方
• 受託/自社SaaSのテックリード：チーム標準のセキュリティ方針・コードテンプレートを整備したい方
• QA/アクセシビリティ担当：エラー表示・2FA・通知などの読み上げ/操作保証も含めて品質を底上げしたい方
• CS/プロダクトオーナー：安全かつ迷わせないUI設計で問い合わせ削減を目指す方

1. はじめに：セキュリティ × アクセシビリティは“両輪”です

セキュリティは誤操作を防ぎ、リスクを最小化する仕組み。アクセシビリティは誰でも迷わず操作できる仕組み。
二つは表裏一体です。たとえばログイン失敗時の曖昧な文言は情報漏えいを防ぎつつも原因が伝わりにくいと離脱の原因に。両立の鍵は「安全に、しかし親切に」。本記事は、実務でそのまま使えるコードと運用Tipsに絞ってお届けします♡

2. まずは全体地図：脅威とLaravelの基本防御

• CSRF：状態変更のリクエストを本人に成りすまし送信 → CSRFトークンで防御
• XSS：悪意あるスクリプトが実行 → Bladeの自動エスケープとCSP
• SQLインジェクション：クエリに任意SQLを混入 → バインディングと生SQLの最小化
• マスアサインメント：意図しないカラムに一括代入 → $fillable/$guarded と 検証済みデータのみに限定
• 認証/認可：なりすまし・権限逸脱 → ハッシュ化・メール検証・ポリシー
• リソース濫用：総当たり/スパム → Rate Limiting
• 情報漏えい：詳細なエラーやログ → マスキング・例外ハンドリング
• ヘッダー欠落：クリックジャッキング等 → セキュリティヘッダー
• CORS誤設定：他オリジンからの誤用 → config/cors.php の厳格化

3. CSRF対策：フォームもAJAXも“トークン必須”

3.1 Bladeフォーム

<form method="POST" action="{{ route('profile.update') }}">
  @csrf
  {{-- フィールド… --}}
  <button type="submit">保存</button>
</form>

Laravelはミドルウェアでトークンを検証します。必ず @csrf を。

3.2 SPA/AJAX（Sanctumを併用する構成が一般的）

// 例：fetch で CSRF トークンを送付
await fetch('/profile', {
  method: 'POST',
  headers: {
    'X-CSRF-TOKEN': document.querySelector('meta[name="csrf-token"]').content,
    'X-Requested-With': 'XMLHttpRequest'
  },
  body: new FormData(document.querySelector('#form'))
});

3.3 クッキー設定（SameSite/secure）

config/session.php を見直し、HTTPS本番では：

'secure'   => env('SESSION_SECURE_COOKIE', true),
'same_site'=> 'lax', // 必要に応じて 'strict'

メモ：SameSiteはCSRF軽減に役立ちますが、トークン検証は必須です。

4. XSS対策：出力はデフォルト“エスケープ”、HTMLは厳格に

4.1 Bladeの基本

{{-- デフォルトはエスケープ --}}
{{ $user->name }}

{{-- 非エスケープは原則禁止（信頼済みの最小限だけ） --}}
{!! $trustedHtml !!}

属性値やデータ属性も必ずエスケープされます。{!! !!} は極力使わないが鉄則。

4.2 リッチテキストの扱い

• 受け入れる場合は許可リスト方式でサニタイズ（例：Markdown → サニタイズ → HTML）。
• 保存時にプレーンテキストも保持し、一覧等ではテキスト版を優先表示。
• プレビューや差分表示では半角記号のエスケープを徹底。

4.3 CSP（Content-Security-Policy）で“万が一”に備える

// app/Http/Middleware/SecurityHeaders.php
namespace App\Http\Middleware;
use Closure;

class SecurityHeaders {
  public function handle($request, Closure $next) {
    $resp = $next($request);
    $csp = "default-src 'self'; img-src 'self' data:; object-src 'none'; frame-ancestors 'none';";
    $resp->headers->set('Content-Security-Policy', $csp);
    $resp->headers->set('X-Content-Type-Options', 'nosniff');
    $resp->headers->set('X-Frame-Options', 'DENY');
    $resp->headers->set('Referrer-Policy', 'strict-origin-when-cross-origin');
    return $resp;
  }
}

• インラインスクリプトを使う場合は nonce か 'self' + ビルド済み外部JSに切替。
• まずはレポートのみで導入 → 違反を洗い出して厳格化が安全です。

5. SQLインジェクション：バインディングが標準、Rawは最小に

// 安全：プレースホルダによるバインディング
DB::select('SELECT * FROM users WHERE email = ?', [$email]);

// Eloquent/Builderは自動でバインディング
User::where('email', $email)->first();

5.1 Rawを使うときの型安全

// OK：orderByのホワイトリスト化
$sort = $request->input('sort');
abort_unless(in_array($sort, ['created_at','title'], true), 400);
$query->orderBy($sort, 'desc');

// NG：ユーザー入力をそのまま Raw に埋め込む

メモ：以前の記事の検索ソート同様、ホワイトリストが基本方針です。

6. マスアサインメント：代入対象を“明示”する

6.1 $fillable で許可カラムを限定

// app/Models/Post.php
class Post extends Model {
  protected $fillable = ['title','body','status'];
}

6.2 検証済みデータだけを流す

// コントローラ
$data = $request->validated(); // FormRequest
$post = Post::create($data);

$guarded = [] は安易に使わない。DTOや専用サービス層でのマッピングも有効です。

7. 認証強化：ハッシュ、検証、試行制限、セッション

7.1 パスワードハッシュと再計算

use Illuminate\Support\Facades\Hash;

if (Hash::needsRehash($user->password)) {
  $user->password = Hash::make($plain);
  $user->save();
}

ハッシュはbcrypt/argon2idのいずれか（環境に合わせ選択）。Hash::make() に委ねます。

7.2 ログイン試行制限（Rate Limiting）

// app/Providers/RouteServiceProvider.php
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

public function boot() {
  RateLimiter::for('login', function ($request) {
    $key = 'login:'.($request->input('email') ?? 'guest').'|'.$request->ip();
    return [Limit::perMinute(5)->by($key)];
  });
}

ルートに ->middleware('throttle:login') を付与して適用。

7.3 メール検証とパスワード再設定

• メール検証：登録後に確認メールを送付、未検証アカウントは一部機能を制限。
• パスワード再設定：送信文言は「該当するアカウントがある場合は」とし、存在可否を明かさない。

7.4 セッション/クッキー設定

// config/session.php（本番の一例）
'secure'    => true,             // HTTPSのみ
'http_only' => true,             // JSアクセス不可
'same_site' => 'lax',            // 状況で 'strict'
'driver'    => 'redis',          // スケールに応じ選択

他端末ログアウト機能も提供し、危険を最小化。

8. 認可：Gate/Policyで“意図した権限”だけを許可

8.1 Policyの基本

// app/Policies/PostPolicy.php
class PostPolicy {
  public function update(User $user, Post $post): bool {
    return $post->user_id === $user->id;
  }
}

// コントローラ
$this->authorize('update', $post);

8.2 403か404か

• 存在の有無を隠したい場合は 404 を返す設計も（列挙耐性）。
• ただしユーザー体験の観点では403 + わかりやすい導線（戻る/トップへ）の方が親切。
• 組織ポリシーとして一貫性を保ちます。

9. Rate Limiting：API/フォームを「静かに守る」

9.1 カスタム制限

// 例：コメント投稿をユーザー単位で制限
RateLimiter::for('comment', fn($req) => [
  Limit::perMinute(20)->by(optional($req->user())->id ?: $req->ip())
]);

ルート側：->middleware('throttle:comment')

9.2 速度制限 vs バースト制限

• バースト制限（一定期間の回数）で濫用を防止。
• 速度制限（インターバル）で連打を抑制。必要に応じレスポンスに戻り時刻を提示。

アクセシビリティ：制限にかかった場合は role="alert" で理由と再試行タイミングを明確に。

10. セキュリティヘッダー：ミドルウェアで一括

// app/Http/Middleware/SecurityHeaders.php（続き）
$resp->headers->set('Strict-Transport-Security', 'max-age=31536000; includeSubDomains; preload');
$resp->headers->set('Permissions-Policy', "geolocation=(), microphone=()");

• HSTS：常時HTTPS化の徹底
• X-Frame-Options / frame-ancestors：クリックジャッキング対策
• Permissions-Policy：不要な機能をオフ
• Referrer-Policy：外部遷移時の参照元を最小化

注意：CSPは段階導入し、機能を壊さないよう検証を重ねましょう。

11. CORS：必要最小限に

config/cors.php を厳格化する例：

'paths' => ['api/*', 'sanctum/csrf-cookie'],
'allowed_methods' => ['GET', 'POST', 'PUT', 'PATCH', 'DELETE'],
'allowed_origins' => ['https://app.example.com'], // ワイルドカードは避ける
'supports_credentials' => true, // 必要なときだけ
'allowed_headers' => ['Content-Type','X-Requested-With','X-CSRF-TOKEN','Authorization'],

原則：開発中の便宜設定を本番へ持ち込まないこと。

12. ファイルアップロード/ダウンロード：公開面と保存面を分離

12.1 アップロード

// バリデーション
$request->validate([
  'avatar' => ['required','file','mimes:jpg,jpeg,png','max:2048'],
]);

// 保存（ユーザー固有ディレクトリ等）
$path = $request->file('avatar')->store('avatars/'.auth()->id());

// DBにはパスのみ保存（元ファイル名は使わない）
$user->update(['avatar_path' => $path]);

• MIME/拡張子の両方で検証
• 公開ディレクトリ直下に置かない（Storage経由で配信）

12.2 ダウンロード：署名付きルート

// routes/web.php
Route::get('/files/{path}', [FileController::class,'show'])
  ->middleware('signed')->name('files.show');

// 生成
$url = URL::temporarySignedRoute('files.show', now()->addMinutes(10), ['path'=>$path]);

• 署名付きURLで改ざん防止
• 必要ならアクセス権を再チェック

代替テキスト：画像をUIに出す際は alt を適切に。アップロード時に説明入力を促すと親切です♡

13. 署名付きURL＆URL署名の活用

• メール内のワンタイム操作（解除・確認）に最適。
• 期限切れ時は role="status" で優しく案内＋再発行リンクを提示。

if (! $request->hasValidSignature()) {
  return redirect()->route('dashboard')
    ->with('status','リンクの有効期限が切れました。もう一度お試しください。');
}

14. データの暗号化：保護すべきは「保存時」も

use Illuminate\Support\Facades\Crypt;

// 保存
$model->secret = Crypt::encryptString($plain);
// 取得
$plain = Crypt::decryptString($model->secret);

• 片方向の比較で十分な値（パスワード等）はHash、復号が必要な値はCrypt。
• APP_KEY は厳重管理し、漏えい時は即時無効化・再発行＋影響範囲の点検。

15. ログのマスキング：個人情報は“書かない”

15.1 マスク処理（Monolog Processor）

// app/Logging/MaskingProcessor.php
class MaskingProcessor {
  public function __invoke(array $record) {
    $record['extra']['masked'] = true;
    $record['message'] = preg_replace('/[0-9a-z._%+-]+@[0-9a-z.-]+\.[a-z]{2,}/i', '[email masked]', $record['message']);
    return $record;
  }
}

// config/logging.php（該当チャンネルに追加）
'processors' => [
  App\Logging\MaskingProcessor::class,
],

原則：トークン/クレデンシャル/PIIはログ禁止。例外メッセージにも気を配る。

16. 2FA（多要素）とアクセシブルなOTP入力

16.1 導入の考え方

• TOTP（認証アプリ）やバックアップコードを用意。
• テキストメッセージのみの2FAは、配送の不確実性や盗聴の懸念あり。
• Laravel Jetstream/Fortify等で標準導入が可能（構成はプロジェクト方針に合わせて）。

16.2 アクセシブルなOTP入力UI

{{-- 単一入力（推奨：貼り付けも楽） --}}
<label for="otp" class="block">6桁の確認コード</label>
<input id="otp" name="otp" inputmode="numeric" autocomplete="one-time-code"
       pattern="\d{6}" aria-describedby="otp-help"
       class="border rounded px-3 py-2 w-48" />
<p id="otp-help" class="text-sm text-gray-600">認証アプリに表示された6桁の数字を入力してください。</p>

{{-- エラー表示は role="alert" + aria-invalid --}}
@error('otp')
  <p class="text-red-700 mt-1" role="alert" id="otp-error">{{ $message }}</p>
@enderror

• 1つの入力に6桁を入れる方式は読み上げ/貼り付けに親切。
• フォーカス移動が不要で、キーボード/スクリーンリーダー双方の操作が楽になります♡

17. エラーメッセージ設計：安全に、でも“直せる言葉で”

• 存在有無を明かさない：「メールアドレスまたはパスワードが正しくありません」
• 修正方法を示す：何文字以上・形式・次の手順
• 読み上げ可能：role="alert"／aria-live、フィールド直下に配置、aria-describedby で紐付け
• 色に依存しない：アイコン/テキスト/枠線の多重表現

@error('email')
  <p id="email-error" role="alert" class="text-red-700">メールアドレスまたはパスワードが正しくありません。</p>
@enderror

18. 依存関係・運用：安全なリリースのために

• composer audit や依存更新の定期運用
• APP_DEBUG=false を必ず本番で徹底
• 例外ページにユーザー向けメッセージ（role="status"）と問い合わせ導線
• バックアップ/復旧手順・秘密情報の保管（環境変数/権限）を明文化
• CIで静的解析/テストを回し、セキュリティミドルウェアの有効性も確認

19. サンプル：セキュリティミドルウェアをまとめて適用

// app/Http/Kernel.php
protected $middleware = [
  // 既定群...
  \App\Http\Middleware\SecurityHeaders::class, // 追加
];

段階導入のすすめ

1. レポートのみCSP → 2) 主要画面で厳格化 → 3) 全面適用。
   破壊的変更になり得るため、小さく回して確実に。

20. E2E/Feature テスト観点（抜粋）

Feature

• CSRFなし送信 → 419 応答を確認
• 認証後の保護ルート → 未ログインで 302→ログイン へ
• Rate Limit超過 → 429 と再試行秒の提示
• 署名付きURL → 期限切れ/改ざんで拒否される

Dusk/E2E（アクセシビリティ）

• ログイン失敗時に role="alert" が読み上げられる
• 2FA入力で単一入力に貼り付け可能
• 制限到達時のエラー文が明確で次の行動を示す

21. チェックリスト（配布用）

入力/フォーム

• [ ] すべてのフォームに @csrf
• [ ] FormRequest で検証、$request->validated() のみ使用
• [ ] エラーは role="alert"/aria-describedby で紐付け

DB/モデル

• [ ] Eloquent/Builderのバインディング使用、生SQLは最小
• [ ] $fillable で代入を限定、DTO/サービス層を検討
• [ ] ソート/列指定はホワイトリスト

認証/認可

• [ ] ハッシュは Hash::make()、needsRehash() の活用
• [ ] ログイン試行は RateLimiter で制限
• [ ] メール検証/パスワード再設定の存在非開示
• [ ] Policyでの行単位認可、403/404方針の統一

HTTP/ヘッダー/CORS

• [ ] HSTS/Frame-Options/CSP/Referrer-Policy/Permissions-Policy
• [ ] CORSは最小許可、ワイルドカード/資格情報併用を避ける

ファイル/URL

• [ ] MIME/拡張子/サイズ検証、公開領域に直置きしない
• [ ] 署名付きURLで改ざん防止、権限チェックを併用

暗号/ログ

• [ ] 片方向はHash、復号が必要なものはCrypt
• [ ] ログからPII/トークンを排除、マスク処理を適用

2FA/UI

• [ ] 2FA有効化（TOTP/バックアップコード）
• [ ] OTPは単一入力を基本、aria-* を適切に

運用

• [ ] APP_DEBUG=false、例外ページのユーザー配慮
• [ ] 依存更新/監査、バックアップ/復旧計画
• [ ] CIでセキュリティテスト・a11yテスト実行

22. まとめ：安全で、やさしいLaravelへ

• CSRF/XSS/SQLi/マスアサインメントの“基本防御”をコードで実装
• 認証強化（ハッシュ/試行制限/検証）とPolicy認可で“権限の壁”を堅牢に
• Rate Limiting・CORS・セキュリティヘッダー・CSPでプラットフォームを底上げ
• 署名付きURL・暗号化・安全なファイル処理でデータを保護
• 2FAとアクセシブルUIで「誰でも、安心して」使える体験へ

セキュリティは“壁”ではなく、安心して使える道案内。
アクセシビリティは“特別”ではなく、みんなのための設計。
今日の小さな改善が、明日の大きな事故を防ぎ、ユーザーの信頼を育てます。ここで紹介したテンプレートとチェックリストをチーム標準にして、堅牢でやさしいLaravelアプリを一緒に育てていきましょうね♡

このガイドが特に役立つ読者像（詳細）

• SaaS/業務システムのテックリード：セキュリティ中核（ヘッダー/CSP/RateLimit/Policy）をミドルウェア/プロバイダに集約し、横断的な品質保証を築きたい。
• QA/アクセシビリティ担当：エラーメッセージ・2FA・制限時のUIの読み上げ・操作保証をテスト項目化し、誰も取り残さない体験を確認したい。
• CS/PO：セキュアで迷わない導線により、アカウント問題の問い合わせや誤操作を継続的に削減したい。
• 個人開発者：基本防御をテンプレ化し、**短期間で“安全な初期状態”**を手に入れたい。