通知APIを、便利にする前に「誰が呼べるか」から閉じた話

今日は、Next.jsとTypeScriptで作っている予約管理システムの通知処理を見直した。

管理画面で予約状況を変更すると、関係者へ案内を送る仕組みがある。画面から正しく使うだけなら問題はない。ただ、通知用のAPIが外部から直接呼べる状態だと、想定していない人が通知処理を動かしたり、まだ確定していない予約まで送信対象にしたりする余地が残る。

そこで今回は、送信内容を増やす前に「誰がこの処理を呼べるか」を先に整理した。APIは運営権限を確認できた場合だけ実行し、一般利用者からの直接呼び出しは拒否する。さらに、予約の途中状態をそのまま通知要求として受け付けず、運営側で確認した状態だけを処理へ渡す形に変更した。

実装で意識したのは、画面のボタンを隠すことと、APIを守ることは別だという点だった。ボタンが見えなくても、URLやリクエストの形が分かれば処理を呼べる場合がある。認証済みかどうかだけでなく、その人が運営操作を行える役割か、受け付けてよい状態かをサーバー側で確認する必要がある。

変更後は権限なし・不正な状態・正常な運営操作の3パターンを分けて確認した。Vercelではデプロイがスキップされたため、本番反映済みとはせず、PRと実装内容の確認までで止めている。

Next.jsの管理画面や通知機能では、見た目の実装だけでなく、認証・権限・状態遷移まで含めて確認します。既存システムのAPI点検や、小さな安全対策の追加からでもご相談ください。