Session-getter failures return early without executing protected logic

Calling const session = await auth() and then immediately proceeding to render data or execute logic without checking if (!session) means the code path runs identically whether the user is authenticated or not. CWE-284 (Improper Access Control) and OWASP A01 apply: a null session is not an error, it's the expected return value when no user is logged in. The absence of a guard after the session call is functionally equivalent to having no auth check at all — the protected logic executes unconditionally.

Add a null-check guard within the first few lines after the session call. The guard must redirect or return before any business logic runs.

// Bad: session called but result ignored
const session = await auth()
const users = await prisma.user.findMany()  // executes even when session is null

// Good: guard immediately
const session = await auth()
if (!session?.user) {
  redirect('/login')
  // or for API routes:
  // return Response.json({ error: 'Unauthorized' }, { status: 401 })
}
const users = await prisma.user.findMany()

The pattern if (!session?.user) redirect('/login') is idiomatic for Next.js App Router server components. For API routes, use an early return Response.json(...) with status 401.