Authorization Logic Centralized
Why it matters
Copy-pasted getSession() + inline if (!session) return 401 blocks in every route handler are a maintenance hazard. When the session-check logic needs to change — adding a new auth provider, switching libraries, or tightening the token validation — every handler must be found and updated. One missed handler leaves an unguarded route. OWASP A01 (Broken Access Control) and CWE-284 explicitly cover the failure mode where access enforcement is inconsistent across handlers. Centralized middleware makes the enforcement surface one file, one audit.
Severity rationale
Low because the immediate security impact is maintenance risk and inconsistency rather than a direct bypass, but the long-term risk of drift is meaningful.
Remediation
Wrap route handlers with a withAuth higher-order function so authentication logic lives in one place. Route handlers receive the verified session as a parameter and never call getSession directly.
// lib/auth/protected-handler.ts
import { auth } from '@/lib/auth';
import { NextRequest, NextResponse } from 'next/server';
type Handler = (req: NextRequest, session: Session) => Promise<NextResponse>;
export function withAuth(handler: Handler) {
return async (req: NextRequest) => {
const session = await auth();
if (!session) return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
return handler(req, session);
};
}
For Next.js App Router, also add middleware.ts to protect entire route groups at the edge before requests reach handlers.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Authorization Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-284 — Improper Access Control
- owasp:2021 · A01
- nist:rev5 · AC-3
Taxons
History
- 2026-04-18·v1.0.0·Initial import from saas-authorization·automated