احراز هویت پاسخ می‌دهد «این درخواست از طرف چه کسی است؟» مجوز دسترسی پاسخ می‌دهد «آیا این هویت اجازه انجام این عملیات روی این منبع را دارد؟» ورود موفق به معنی اجازه خواندن تمام رکوردها یا اجرای همه عملیات نیست.

احراز هویت پاسخ می‌دهد «این درخواست از طرف چه کسی است؟» مجوز دسترسی پاسخ می‌دهد «آیا این هویت اجازه انجام این عملیات روی این منبع را دارد؟» ورود موفق به معنی اجازه خواندن تمام رکوردها یا اجرای همه عملیات نیست.

مدیریت session

برای ساخت و چرخش session، انقضا و مدیریت کوکی از کتابخانه احراز هویت نگه‌داری‌شده استفاده کن. کوکی session باید HttpOnly باشد و در production از Secure استفاده کند؛ سیاست SameSite را هم متناسب با جریان ورود انتخاب کن. secretهای بلندمدت را در localStorage نگذار و کلیدهای فقط-سرور را وارد bundle کلاینت نکن.

اعمال مجوز دسترسی در سرور

کنترل دسترسی را در همان مرز سروری اجرا کن که عملیات را انجام می‌دهد. مخفی‌کردن لینک مدیریت یا غیرفعال‌کردن دکمه فقط رابط کاربری را بهتر می‌کند و کنترل دسترسی نیست. هر Server Action و Route Handler باید session فعلی و منبع درخواستی را بررسی کند.

ساخت guard قابل استفاده مجدد

import { auth } from '@/lib/auth';
import { headers } from 'next/headers';
import { redirect } from 'next/navigation';

export async function requireAdmin() {
  const session = await auth.api.getSession({ headers: await headers() });
  if (!session) redirect('/login');
  if (session.user.role !== 'admin') redirect('/unauthorized');
  return session.user;
}

یک guard مشترک، سیاست دسترسی را شفاف می‌کند. API دقیق session و مدل نقش‌ها به تنظیمات احراز هویت تو وابسته است؛ این نمونه یک الگوست و باید با نسخه نصب‌شده Better Auth و typeهای پروژه تطبیق داده شود.

محافظت از هر mutation

'use server';

export async function deleteUser(userId: string) {
  const actor = await requireAdmin(); // Never trust a role sent by the browser
  if (actor.id === userId) throw new Error('Cannot delete your own account');

  await db.user.delete({ where: { id: userId } });
  return { success: true };
}

guard را داخل هر mutation حساس فراخوانی کن، نه فقط در صفحه‌ای که لینک آن عملیات را دارد. کاربر می‌تواند Server Action را مستقیم فراخوانی کند. منبع هدف را هم اعتبارسنجی کن: بررسی نقش به‌تنهایی مانع ویرایش رکورد کاربر دیگر نمی‌شود، اگر قانون مالکیت را بررسی نکنی.

استفاده از قواعد دیتابیس

برای قواعدی که حتی باگ برنامه نباید نقضشان کند از constraintهای دیتابیس استفاده کن؛ مثل ایمیل یکتا، foreign key و روابط معتبر. در برنامه چندمستاجری، queryها را با tenant و مالکیت منبع محدود کن؛ همه داده‌ها را نخوان تا بعداً رابط کاربری فیلترشان کند.

محافظت از جریان‌های جانبی

محافظت CSRF، محدودیت تعداد تلاش در ورود و OTP، انقضای توکن بازیابی رمز و پیام خطای عمومی را بررسی کن تا وجود حساب افشا نشود. رویدادهای امنیتی را ثبت کن، اما رمز، توکن خام یا کوکی کامل session را در log ننویس.

چک‌لیست تصمیم‌گیری

دسترسی بدون ورود، تلاش کاربر عادی برای عملیات مدیر، درخواست منبع کاربر دیگر، session منقضی و درخواست‌های تکراری را تست کن. امنیت ویژگی مسیر داده سمت سرور است، نه ظاهر رابط کاربری.