Laravel ابزارهای امنیتی خوبی دارد، اما framework نمی‌تواند منطق دسترسی، آپلود فایل یا تنظیم اشتباه سرور را به‌جای ما تصمیم بگیرد. این چک‌لیست امنیت Laravel را بهتر است پیش از انتشار و سپس در بازبینی‌های دوره‌ای اجرا کنید؛ نه فقط بعد از یک اتفاق.

تنظیمات و secretها

  • APP_DEBUG=false و محیط production درست تنظیم شده باشد.
  • فایل .env و backup آن از مسیر عمومی قابل دریافت نباشد.
  • کلیدها در Git نباشند و برای هر محیط مقدار جدا داشته باشند.
  • پس از خروج همکار، tokenها و دسترسی‌های مرتبط rotate شوند.

پیام خطای production نباید stack trace، SQL یا مسیر سرور را نشان دهد. جزئیات باید با request ID در log امن ثبت شوند.

Authentication با Authorization فرق دارد

لاگین موفق فقط هویت را مشخص می‌کند. برای هر عملیات و هر رکورد باید مجوز بررسی شود. Policy و Gate منطق را متمرکز می‌کنند. مخفی‌کردن دکمه در فرانت امنیت نیست؛ endpoint باید مستقل تصمیم بگیرد.

سناریوی مهم تست این است: کاربر A شناسه رکورد کاربر B را در URL یا body می‌فرستد. اگر فقط model binding داشته باشیم، احتمال IDOR وجود دارد.

ورودی، query و خروجی

Form Request نوع، طول، format و مقادیر مجاز را کنترل می‌کند. bindingهای Eloquent جلوی بسیاری از injectionها را می‌گیرند، ولی orderBy($request->input('sort')) یا raw SQL با ورودی مستقیم خطرناک است. نام ستون و فیلتر باید whitelist شوند.

Blade با {{ }} خروجی را escape می‌کند. استفاده از {!! !!} فقط برای HTML قابل اعتماد مجاز است. محتوای rich text کاربر باید با sanitizer معتبر و policy روشن پاک‌سازی شود.

آپلود فایل را مثل ورودی فعال ببینید

  • پسوند را کافی ندانید؛ MIME و محتوای فایل را بررسی کنید.
  • نام فایل تصادفی و مسیر خارج از اجرای PHP باشد.
  • اندازه، تعداد و ابعاد تصویر محدود شوند.
  • برای فایل حساس، لینک موقت و authorization لازم است.
  • پردازش پیچیده در worker محدود و sandbox شود.

Session، token و rate limit

Cookie باید Secure، HttpOnly و SameSite مناسب داشته باشد. session بعد از login regenerate شود. tokenها حداقل scope و امکان revoke داشته باشند و هرگز در log چاپ نشوند. login، بازیابی رمز، OTP، جستجوی گران و endpoint عمومی rate limit متفاوت می‌خواهند.

Dependency و زیرساخت

composer audit و هشدارهای امنیتی را در CI ببینید، اما update کور هم خطر دارد. patch را در محیط staging با تست اجرا کنید. نسخه PHP، وب‌سرور، دیتابیس و سیستم‌عامل نیز بخشی از سطح حمله‌اند.

وب‌سرور باید فقط پوشه public را expose کند. directory listing، endpointهای admin و سرویس‌های داخلی را محدود کنید. backup رمزنگاری‌شده بدون تست بازیابی، هنوز برنامه بازیابی محسوب نمی‌شود.

لاگ مفید بدون افشای داده

ورود ناموفق، تغییر سطح دسترسی، عملیات مالی و تغییر تنظیمات حساس باید audit trail داشته باشند. رمز، token، شماره کامل کارت و داده شخصی غیرضروری را log نکنید. دسترسی به log هم خودش نیازمند کنترل است.

بازبینی را بر اساس ریسک انجام دهید

همه موارد شدت یکسان ندارند. مسیری که پول، داده شخصی یا دسترسی مدیر را کنترل می‌کند اولویت بالاتری از header کم‌اثر دارد. یافته‌ها را با شواهد، اثر و راه اصلاح ثبت کنید.

برای بررسی مستقل کد و زیرساخت، ممیزی فنی Laravel خروجی اولویت‌بندی‌شده ارائه می‌کند. اگر API عمومی دارید، استانداردهای طراحی امن API در Laravel را هم مرور کنید.

پرسش‌های متداول

آیا Eloquent جلوی تمام SQL Injectionها را می‌گیرد؟

Bindingهای Eloquent امن‌اند، اما raw query، نام ستون پویا و ورودی اعتبارسنجی‌نشده همچنان می‌توانند خطر ایجاد کنند.

APP_DEBUG در production چه خطری دارد؟

ممکن است stack trace، مسیر فایل، تنظیمات و جزئیات حساس برنامه را در اختیار مهاجم قرار دهد.