امنیت Laravel از فرم تا سرور

اول مسیر داده و دسترسی را بشناسید

A useful threat model begins with a map of trust boundaries: browser to application, public route to authenticated route, user to role, application to storage, queue to worker, and deployment operator to production. For every boundary, write down what enters, who is allowed to trigger it, what changes, and how the decision is recorded.

قبل از انتخاب ابزار امنیتی، مسیرهای ورود داده و تغییر دسترسی را روی کاغذ بیاورید: مرورگر به برنامه، کاربر مهمان به حساب واردشده، برنامه به فضای ذخیره‌سازی و صف به پردازش پس‌زمینه. برای هر مسیر مشخص کنید چه داده‌ای وارد می‌شود، چه کسی اجازه انجام کار را دارد و نتیجه کجا ثبت می‌شود.

This changes security reviews from vague questions into testable claims. Instead of asking whether a project is secure, ask whether a customer can read another customer’s invoice, whether a forged webhook can change payment state, or whether an uploaded SVG can execute in an administrator’s browser.

این کار سؤال مبهم «سایت امن است؟» را به چند بررسی مشخص تبدیل می‌کند. آیا مشتری می‌تواند فاکتور فرد دیگری را باز کند؟ آیا پیام جعلی سرویس پرداخت می‌تواند وضعیت سفارش را تغییر دهد؟ آیا فایل ارسالی کاربر امکان اجرای کد در مرورگر مدیر را دارد؟ هر پاسخ باید با بررسی یا آزمون پشتیبانی شود.

ورود به حساب با اجازه انجام کار فرق دارد

Laravel makes authentication approachable, but a valid session is not permission to perform every action. Policies and gates should express ownership, role, tenant, and resource state on the server. Hiding a button in the interface improves clarity; it does not create a security boundary.

اینکه کاربر با موفقیت وارد حساب شده، به او اجازه هر کاری نمی‌دهد. در Laravel، قواعد Policy و Gate باید روی سرور مالکیت داده، نقش کاربر، سازمان مربوط و وضعیت رکورد را بررسی کنند. پنهان کردن دکمه در صفحه برای تجربه کاربری مفید است، اما جای کنترل دسترسی را نمی‌گیرد.

Sensitive actions deserve fresh confirmation, narrow rate limits, predictable session invalidation, and an audit record. Account recovery should be treated as an authentication flow in its own right: tokens expire, old links become useless, responses avoid revealing whether an account exists, and privileged sessions can be revoked.

برای کارهای حساس، تأیید دوباره هویت، محدودیت تعداد درخواست و ثبت سابقه فعالیت لازم است. بازیابی حساب هم باید به اندازه ورود جدی گرفته شود: لینک‌ها زمان اعتبار محدود داشته باشند، استفاده دوباره از لینک قدیمی ممکن نباشد و پاسخ برنامه بی‌دلیل وجود حساب یک فرد را افشا نکند.

هر ورودی را پیش از استفاده بررسی کنید

Validation should constrain shape, size, type, range, and business meaning. File uploads need generated names, storage outside executable paths, server-side MIME inspection, strict size limits, and delivery headers that prevent interpretation as active content. Never trust the extension supplied by the client.

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

Webhooks, imports, and background jobs are also input surfaces. Verify signatures before parsing side effects, make handlers idempotent, cap retries, and retain enough correlation data to reconstruct what happened without logging secrets. A queue separates time; it does not remove authorization or validation requirements.

پیام سرویس‌های بیرونی، فایل‌های واردشده و کارهای پس‌زمینه هم ورودی محسوب می‌شوند. پیش از تغییر داده، امضای پیام را بررسی کنید. پردازش تکراری یک پیام نباید دوباره همان اثر را ایجاد کند؛ مثلاً یک پرداخت را دو بار ثبت کند. تعداد تلاش مجدد را محدود کنید و برای پیگیری خطا، شناسه رخداد نگه دارید؛ نه رمز و اطلاعات محرمانه.

تنظیمات سرور هم بخشی از محصول است

Secrets belong in environment-specific secret stores, not source control, build output, logs, screenshots, or browser-delivered JavaScript. Production should run with debug disabled, minimal filesystem permissions, a dedicated service account, TLS, controlled outbound access, and dependencies updated through a reviewed process.

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

Backups are only evidence of resilience after a restore test. Record recovery objectives, encrypt copies, separate credentials from the primary host, and regularly verify that database, user files, and configuration can be reconstructed together. Monitoring should alert on outcomes—failed logins, permission denials, queue exhaustion, backup age—not just server uptime.

تا وقتی یک نسخه پشتیبان را بازیابی نکرده‌اید، از قابل استفاده بودنش مطمئن نیستید. بررسی کنید پایگاه داده، فایل‌های کاربران و تنظیمات لازم با هم قابل بازگردانی باشند. پایش سرویس هم باید فراتر از روشن بودن سرور برود: ورودهای ناموفق، خطاهای دسترسی، صف‌های متوقف‌شده و قدیمی شدن نسخه پشتیبان، هرکدام معنای متفاوتی دارند.

پیش از انتشار، چند بررسی مشخص داشته باشید

The best baseline is short enough to run on every release and specific enough to fail. Automate framework tests, static checks, dependency review, migration safety, secret scanning, and representative authorization tests. Then add a human gate for backup freshness, rollback readiness, infrastructure health, and live verification of the paths that carry the most risk.

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

• دسترسی نقش‌ها و مالکیت داده روی سرور بررسی شده است.
• فایل‌های ارسالی محدود، بررسی‌شده و غیرقابل اجرا هستند.
• رمز و کلید سرویس در کد یا گزارش‌ها قرار ندارد.
• بازیابی نسخه پشتیبان، بازگشت نسخه و مسیرهای اصلی بررسی شده‌اند.