Next.js Server Actionsのセキュリティ完全ガイド　仕組みとリスク・実践対策

2026.08.02

Next.jsの「Server Actions」は、フォーム送信やデータ更新のためにわざわざAPI Routeを書かなくても、コンポーネントの中に直接サーバー処理を書けてしまう便利な機能です。しかし「関数を呼んでいるだけ」という見た目の裏側では、コンパイル時にその関数が公開エンドポイントへと変換されています。つまりServer Actionsは実質的にAPIであり、通常のAPI Routeと同じレベルのセキュリティ対策が必要です。この記事では、Next.js Server Actionsのセキュリティをテーマに、仕組みの正しい理解から具体的な脆弱シナリオ、そして実務で使えるBefore/Afterのコード例まで、体系的に解説します。

Server Actionsとは何か　仕組みのおさらい

Server Actionsは、Next.js 14で正式にリリースされた機能で、"use server"ディレクティブを付けた関数をサーバー側でのみ実行させることができます。フォームのaction属性へ直接渡したり、クライアントコンポーネントからイベントハンドラ経由で呼び出したりと、これまでフロントエンドとバックエンドで分かれていたコードを同じファイルにまとめて書けるのが最大の特徴です。

コンパイル時に「隠れたPOSTエンドポイント」へ変換される

ここで押さえておくべき重要な事実があります。"use server"を付けた関数は、ビルド時にNext.jsによって自動的にサーバー側のエンドポイントとして切り出され、クライアント側のコードにはその関数を呼び出すためのfetchリクエストが埋め込まれます。実際にブラウザの開発者ツールでネットワークタブを開くと、Server Actionを呼び出すたびにPOSTリクエストが発生していることが確認できます。このリクエストにはServer Actionを一意に識別するIDがヘッダーに含まれており、原理上はcurlなどのHTTPクライアントから直接同じエンドポイントを叩くことも可能です。

つまり開発者から見ると「サーバー関数をimportして呼んでいるだけ」に見えても、実行時の実体は紛れもなく「認証されていない第三者からも到達しうるHTTPエンドポイント」です。この認識のズレこそが、Server Actionsまわりのセキュリティ事故が起きやすい根本原因です。

クロージャ変数の暗号化とその限界

Server Actionは、外側のスコープにある変数（クロージャ）を参照できます。この場合、Next.jsはその変数の値をサーバー側の秘密鍵を使って暗号化し、クライアントとの間でやり取りされるペイロードに埋め込みます。これにより変数の値そのものが平文でブラウザに渡ることは防がれますが、あくまで「暗号化されて見えなくなっている」だけであり、暗号化に使う鍵がサーバー側から漏洩すれば、そのクロージャ変数も復号されうるという前提を忘れてはいけません。クロージャの暗号化は利便性のための仕組みであって、認可・検証を代替するものではない点は明確に区別しておく必要があります。

なぜServer Actionsはセキュリティリスクを生みやすいのか

「関数呼び出し」に見えることが油断を生む

REST APIやAPI Routeを設計するときは、多くの開発者が自然に「これは外部から叩かれるエンドポイントだ」と意識し、認証・認可・入力検証を実装します。ところがServer Actionsは見た目が通常の非同期関数であるため、「同じファイル・同じコンポーネントの中でしか呼ばれないはず」という誤った前提のもとにコードが書かれがちです。実際には前述の通り、コンパイル後は誰でも到達可能なPOSTエンドポイントになっているため、この思い込みがそのまま認可漏れや検証漏れに直結します。

UIの表示制御とサーバー側の認可は別物

「管理者用のボタンは管理者にしか表示していないから安全」という考え方も典型的な落とし穴です。ボタンやフォームの表示・非表示はあくまでクライアント側のUI制御にすぎず、Server Action自体のエンドポイントには誰でも到達できます。UIの見た目上の制約と、サーバー側で必須となる認可チェックは、常にセットで実装しなければなりません。

具体的な脆弱シナリオ

シナリオ1　認可チェック漏れによる不正な削除・更新

投稿の削除やユーザー情報の更新を行うServer Actionで、リクエスト元のユーザーがその対象に対する権限を持っているかを確認していないケースです。IDだけを受け取って処理を実行してしまうと、悪意のある第三者が他人のリソースのIDを推測・列挙して送り込むだけで、削除や改ざんが成立してしまいます。

シナリオ2　パストラバーサル・任意ファイルアクセス

ファイルパスや識別子を引数として受け取り、サーバー内のファイルを読み書きするServer Actionでは、入力値の検証を怠ると../../のような相対パス指定によって、意図しないディレクトリのファイルへアクセスされる可能性があります。

シナリオ3　大容量入力によるDoS・メモリ枯渇

画像などをBase64エンコードしてServer Actionへ渡す実装は手軽ですが、サイズ制限をかけていないと、大きなペイロードを繰り返し送りつけられるだけでサーバーのメモリを圧迫し、可用性の低下を招く恐れがあります。Next.jsにはボディサイズの既定の上限がありますが、機能要件に応じて明示的に設定を見直しておくことが望ましいです。

シナリオ4　レスポンスへの秘密情報の混入

デバッグ目的やオブジェクトをまるごと返す実装のクセで、環境変数やデータベース接続情報、内部的なフラグなどがレスポンスオブジェクトに含まれてしまうことがあります。Server Actionのレスポンスはネットワーク越しにクライアントへ届くため、意図せず機密情報が漏洩する経路になり得ます。

実践的セキュリティ対策　Before/Afterで理解する

対策1　すべてのServer Actionで認可チェックを行う

「同じコンポーネント内からしか呼ばれない」という前提を捨て、Server Actionの冒頭で必ずログインユーザーの取得とリソースの所有者チェックを行います。

Before（認可チェックなし）

'use server'

export async function deletePost(postId: string) {
  await db.post.delete({ where: { id: postId } })
}

After（認証・認可チェックを追加）

'use server'

import { getCurrentUser } from '@/lib/auth'

export async function deletePost(postId: string) {
  const user = await getCurrentUser()
  if (!user) {
    throw new Error('Unauthorized')
  }

  const post = await db.post.findUnique({ where: { id: postId } })
  if (!post || post.authorId !== user.id) {
    throw new Error('Forbidden')
  }

  await db.post.delete({ where: { id: postId } })
}

対策2　入力値はサーバー側で必ずスキーマ検証する

クライアント側のフォームバリデーションはUX向上のためのものであり、セキュリティの担保にはなりません。Server Actionの内部で、受け取った引数をスキーマに沿って検証し、想定外の値であれば即座に処理を中断します。パス文字列を扱う場合は、許可されたディレクトリ配下であることも合わせて確認します。

Before（検証なしでファイルパスをそのまま使用）

'use server'

export async function readContentFile(path: string) {
  return fs.readFileSync(path, 'utf-8')
}

After（スキーマ検証＋許可ディレクトリ配下の確認）

'use server'

import { z } from 'zod'
import path from 'node:path'
import fs from 'node:fs'

const fileNameSchema = z.string().regex(/^[a-zA-Z0-9_-]+\.md$/)

const CONTENT_DIR = path.resolve('./content')

export async function readContentFile(fileName: string) {
  const validated = fileNameSchema.parse(fileName)
  const resolved = path.resolve(CONTENT_DIR, validated)

  if (!resolved.startsWith(CONTENT_DIR)) {
    throw new Error('Invalid path')
  }

  return fs.readFileSync(resolved, 'utf-8')
}

対策3　ペイロードサイズの制限とレート制限

大容量データを扱うServer Actionでは、想定される入力サイズの上限を明示的に決めておき、それを超える場合はエラーとして扱います。加えて、同一ユーザー・同一IPからの短時間での連続呼び出しを制限する仕組み（レート制限）を組み合わせることで、意図的な過負荷やブルートフォース的な呼び出しへの耐性を高められます。

'use server'

import { rateLimit } from '@/lib/rate-limit'

const MAX_BASE64_LENGTH = 2_000_000 // 約1.5MB相当

export async function uploadAvatar(userId: string, base64Image: string) {
  const allowed = await rateLimit(userId, { limit: 5, windowSeconds: 60 })
  if (!allowed) {
    throw new Error('Too many requests')
  }

  if (base64Image.length > MAX_BASE64_LENGTH) {
    throw new Error('Payload too large')
  }

  // ここから先で保存処理を行う
}

対策4　レスポンスには必要最小限のフィールドだけを含める

データベースの取得結果やオブジェクトをそのままクライアントへ返すのではなく、返却用の型を別途定義し、公開してよいフィールドだけを明示的に選んで返すようにします。

Before（オブジェクトをそのまま返却）

'use server'

export async function getUserProfile(userId: string) {
  return await db.user.findUnique({ where: { id: userId } })
}

After（返却フィールドを明示的に絞り込む）

'use server'

export async function getUserProfile(userId: string) {
  const user = await db.user.findUnique({
    where: { id: userId },
    select: {
      id: true,
      name: true,
      avatarUrl: true,
      // パスワードハッシュや内部トークン、環境変数などは含めない
    },
  })

  if (!user) {
    throw new Error('Not found')
  }

  return user
}

対策5　CSRF対策とオリジン検証を過信しない

Server Actionsにはオリジンの検証など一定のCSRF対策の仕組みが組み込まれているとされていますが、これはあくまで多層防御の一部と捉えるべきです。決済処理や退会処理のような重要な操作では、Server Action任せにせず、アプリケーション側でも改めてユーザーの本人確認（再認証や確認ダイアログ）を挟む、といった追加の防御を検討してください。フレームワーク標準の保護機構に全面的に依存する設計は避けるのが安全です。

Server Actionsセキュリティ実装チェックリスト

  • すべてのServer Actionで「誰でも到達できる公開エンドポイントである」という前提に立っているか
  • ログインユーザーの取得と認可チェック（所有者確認・権限確認）を関数の先頭で行っているか
  • 受け取る引数をスキーマ（zodなど）で検証し、想定外の値を弾いているか
  • ファイルパスや識別子を扱う場合、許可された範囲外へのアクセスを防いでいるか
  • 大容量データを扱うServer Actionにペイロードサイズの上限を設定しているか
  • 連続呼び出しに対するレート制限を導入しているか
  • レスポンスに環境変数・パスワードハッシュ・内部トークンなど機密情報を含めていないか
  • UIの表示制御とサーバー側の認可チェックを混同していないか
  • 重要な操作（決済・退会・権限変更など）に追加の確認ステップを設けているか
  • クロージャ変数の暗号化を「絶対に安全」とみなさず、機密性の高い値はそもそも渡さない設計になっているか

まとめ

Next.jsのServer Actionsは、フロントエンドとバックエンドの境界を取り払い、開発効率を大きく高める魅力的な機能です。しかしその実体は、コンパイル時に生成される公開HTTPエンドポイントであり、通常のAPI Routeやバックエンド関数と同じレベルの警戒心を持って設計・実装する必要があります。「関数を呼んでいるだけ」という見た目に引きずられず、認可チェック・入力検証・レスポンスの絞り込み・レート制限といった基本的なセキュリティ対策を一つひとつ積み重ねることが、Server Actionsを安全に活用するための最も確実な近道です。この記事のチェックリストを、実装レビューやコードレビューの際にぜひ活用してください。

コメント

タイトルとURLをコピーしました