اگر صفحهٔ سایت باز می‌شود ولی ذخیرهٔ یک فرم با خطای ۴۰۳ متوقف می‌شود، یکی از احتمال‌ها ModSecurity یا WAF است؛ کد403 به‌تنهایی این علت را ثابت نمی‌کند. برای بررسی سریع‌تر، زمان دقیق، مسیر درخواست و شناسهٔ رخدادِ قابل‌اشتراک را جمع کنید. خاموش‌کردن کلی حفاظت، قدم اول مناسبی برای تشخیص نیست.
۱. خطای فرم را از خطای دسترسی جدا کنید
| الگو | احتمال‌هایی که باید بررسی شوند |
|---|---|
| فقط یک فرم یا محتوای خاص رد می‌شود | قانون WAF، اعتبارسنجی برنامه، nonce یا مجوز کاربر |
| همهٔ صفحه‌ها برای یک نفر بسته‌اند | IP، شبکه، CDN یا محدودیت ورود |
همهٔ کاربران روی همهٔ مسیرها 403 دارند |
تنظیم وب‌سرور، دسترسی یا حفاظت گسترده |
پیام خطای برنامه بدون رد HTTP |
ممکن است مشکل در خود فرم باشد |
تغییر پرمیشن به ۷۷۷ یا پاک‌کردن htaccess از روی همین نشانه، تشخیص نیست و می‌تواند مشکل دیگری بسازد. ابتدا ثبت کنید درخواست کدام مسیر، با چه متد و در چه ساعت رد شده است.
۲. بستهٔ شواهدِ کم‌حجم و مفید
- تاریخ و ساعت همراه منطقهٔ زمانی.
- نام دامنه و مسیر لازم؛ پارامتر حاوی توکن حذف شود.
- متد درخواست، مانند POST، و کد پاسخ مشاهده‌شده.
- عمل مورد انتظار، مانند ذخیرهٔ متن فرم، و نتیجهٔ واقعی.
- شناسهٔ درخواست یا رخداد اگر صفحه یا لاگ ارائه کرده است.
- شرح اینکه مشکل برای چه حساب یا مرورگری رخ می‌دهد، بدون ارسال رمز و کوکی.
اگر خطا قبلاً رخ داده، اول از شواهد موجود استفاده کنید؛ برای گرفتن عکس درخواست‌های تکراری یا متن حمله به سایت زنده نفرستید. در این مقاله هیچ مسدودسازی عمدی یا آزمون payload روی حساب انجام نشده است.
۳. لاگ را از کجا بخوانیم؟
در سی‌پنل، بخش Metrics و ابزار Errors می‌تواند پیام‌های خطای در دسترس حساب را نشان دهد؛ همهٔ audit logهای WAF الزاماً آنجا نیستند. تصویر واقعی زیر فقط محل و توضیح این ابزار را نشان می‌دهد؛ محتوای خصوصیِ لاگ از کادر خارج شده است.
در حساب بررسی‌شده، رابط ModSecurity در فهرست ابزارها وجود نداشت. وجود یا نبود آن به قابلیت‌های فعال ارائه‌دهنده وابسته است. این نبودن، خاموش‌بودن WAF را هم ثابت نمی‌کند؛ برای لاگ تخصصی، پشتیبانی باید رخداد همان ساعت را در لایهٔ مربوط بررسی کند.
۴. از شناسهٔ قانون چه نتیجه‌ای بگیریم؟
در CRS ممکن است یک تراکنش سالم با الگوی عمومیِ حمله تطبیق پیدا کند؛ به آن false positive گفته می‌شود. اما برای تأیید، باید قانون، هدف تطبیق و زمینهٔ درخواست بررسی شوند. شناسهٔ قانون به‌تنهایی مجوز حذف قانون برای همهٔ سایت نیست.
متن کامل بخش matched data ممکن است همان دادهٔ خصوصی فرم را شامل شود. برای اشتراک‌گذاری عمومی، مقدار را پاک کنید و فقط زمینهٔ ضروری را نگه دارید. پشتیبانی در مسیر امن می‌تواند مشخص کند چه دادهٔ بیشتری واقعاً لازم است.
نکته: لاگ، HAR یا دستور Copy as cURL می‌تواند کوکی و Authorization داشته باشد. فایل خام را در چت عمومی یا ابزار هوش مصنوعی قرار ندهید. عکس هم باید پیش از ارسال، بلور موضعی واقعاً ناخوانا داشته باشد.
۵. نمونهٔ تیکت بدون اطلاعات محرمانه
زمان: 2026-10-24 14:30 +03:30
مسیر: /contact
متد: POST
پاسخ مشاهده‌شده: 403
عمل: ارسال فرم تماس با محتوای عادی
شناسه رخداد: فقط در صورت نمایش و مجازبودن اشتراک
درخواست: بررسی تطبیق لاگ WAF با همین زمان و مسیر
این متن نمونه است و گزارش رخداد واقعی یک دامنه نیست. به پشتیبانی بگویید بدون کاهش سراسری حفاظت، علت بررسی شود. اگر استثنای دقیق لازم باشد، دامنهٔ اثر، بازهٔ اجرا و آزمون مجدد درخواست سالم و حفاظت باید در طرح تغییر مشخص شود؛ این مقاله چنین تغییری اجرا نمی‌کند.
۶. پایان بررسی چه شکلی است؟
نتیجه باید بگوید کدام لایه درخواست را رد کرده و شاهد چیست؛ اگر هنوز معلوم نیست، همان عدم‌قطعیت ثبت شود. برای مسیر عمومی ۴۰۳ و خواندن لاگ، راهنماهای موجود مکمل‌اند. اگر شواهد را آماده کرده‌اید، از مسیر تیکت مجاز خودتان بفرستید؛
۷. مسیر مطالعهٔ مرتبط
- خطای ۴۰۳ Forbidden و سطح دسترسی فایل‌ها؛ ۶۴۴ و ۷۵۵ یعنی چه؟
- خطاهای سایت در سی‌پنل؛ بررسی لاگ و رفع خطای ۵۰۰ و ۴۰۳
- ثبت و پیگیری تیکت پشتیبانی در رایکت
۸. منابع و روش بررسی
منابع رسمی در ۲۴ اکتبر ۲۰۲۶ بررسی شدند. این متن راهنمای تشخیص و برنامه‌ریزی است؛ بازیابی بکاپ، تغییر حفاظت و تست روی سایت زنده انجام نشده است.
