Authorization Failures Return 403

Returning HTTP 200 with an error body on authorization failures breaks API client error handling — clients that check response.ok will treat the failure as a success. Returning HTTP 500 from an unhandled exception when unauthorized access is attempted leaks implementation details (CWE-209). Returning HTTP 302 redirects from API routes sends HTML to JSON clients. These response code errors make authorization failures invisible to automated monitoring and difficult to debug. OWASP A01 (Broken Access Control) and CWE-284 both require that unauthorized access be denied with correct HTTP semantics, not masked behind incorrect status codes.

Return explicit, semantically correct status codes: 401 for unauthenticated, 403 for authenticated-but-unauthorized, and 404 when the resource's existence should not be revealed to the caller.

export async function GET(req: NextRequest, { params }) {
  const session = await auth();
  if (!session) {
    return NextResponse.json({ error: 'Authentication required' }, { status: 401 });
  }

  const resource = await db.document.findFirst({
    where: { id: params.id, userId: session.user.id },
  });
  if (!resource) {
    // 404 hides whether the document exists at all
    return NextResponse.json({ error: 'Not found' }, { status: 404 });
  }

  return NextResponse.json(resource);
}

Never return 200 with an error payload from authorization failures — this pattern silently breaks every client that relies on HTTP status codes for error detection.