همانطور که شما در حال ساخت برنامه های کاربردی هستید، مهم است که اصل رازداری را در نظر داشته باشید. اطلاعات بیشتری از آنچه نیاز هست را در اختیار دیگران قرار ندهید. این بحث در مورد پیام های خطایی که در سایت خود نمایش می دهید صدق می کند. در طول زمان توسعه نرم افزار، برای عیب یابی و رفع اشکالات، باید گزارش خطای دقیق را مشاهده و بررسی کنید. اما در زمان ارائه محصول، مطمئن شوید که نمایش خطاهایی که با جزئیات ارائه می شوند را خاموش کرده اید.
به عنوان مثال، خطاهای لایه دسترسی به داده (Access Layer) می تواند اطلاعات حساسی را در مورد پایگاه داده شما نشان دهد. کاربران نهایی فقط باید بدانند که مشکلی پیش آمده است و برای دریافت راهنمایی و کمک با چه کسی تماس بگیرند. هر گونه اطلاعات اضافی فقط برای هکرها مفید است که از این بازخورد برای برنامه ریزی روش بعدی حمله خود استفاده می کنند.
این امر به ویژه در صفحات حساس مانند صفحه ورود به سیستم بسیار مهم است. اگر تلاش برای ورود ناموفق بود، اطلاعات خاصی در مورد علت شکست در ورود به سایت ندهید، مانند "نام کاربری پیدا نشد". در عوض، از یک پیام خطای عمومی استفاده کنید. همین امر در مورد صفحه بازیابی گذرواژه فراموش شده نیز صدق می کند، جایی که مهاجم ممکن است سعی کند با مشاهده پاسخ خطا، نام های کاربری معتبر را حدس بزند. این بدان معنا نیست که سیستم شما نباید اطلاعات دقیق خطا را به صورت مخفی و محرمانه ثبت کند. بسیار مهم است که مکانیزمی برای ثبت خطاها و رویدادهای حیاتی سیستم داشته باشید تا تیم توسعه بتواند آنها را برطرف کند.
اما حتی هنگام ثبت در پایگاه داده یا فایل‌های لاگ، مطمئن شوید که داده‌های حساس مانند رمزهای عبور به صورت متن ساده ( رمزگذاری نشده) ثبت نشوند و شماره کارت اعتباری را حذف می‌کنید. پروژه های ASP.NET Core معمولاً شامل کد های مترادفی برای رسیدگی به خطا هستند. متد پیکربندی (Configure) را مشاهده بفرمایید. اگر محیط میزبانی فعلی، محیط در حال توسعه است، با استفاده از صفحه نمایشِ خطاهای محیطِ توسعه، خطاها با جزئیات دقیق نشان داده می‌شوند.
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
این باید قبل از اضافه کردن میان افزار MVC که خطا ها را دریافت می کند، اضافه شود. و هنگامی که برنامه در مرحله استفاده مشتریان در حال اجراست، جزئیات خطاها نباید به صورت عمومی به اشتراک گذاشته شود.
در عوض این کار کاربران به یک صفحه مدیریت خطاهای سفارشی سازی شده هدایت می شوند.
else
{
app.UseExceptionHandler("/Home/Error");
}
ما یک صفحه خطای سفارشی را در زیر پوشه Shared اضافه کرده ایم.
این صفحه عمدتاً محتوای ثابتی دارد. شما باید از نوشتن کد در اینجا اجتناب کنید زیرا ممکن است خود این کد منجر به ایجاد خطا در خود صفحه نمایش خطا شود.
می توانید این کار را دقیق تر و کامل تر انجام دهید و کدهای وضعیت HTTP را با صفحات خطای مختلف مدیریت کنید. یعنی خطا های گوناگون رو به صفحات گوناگون هدایت کنید.
فقط مطمئن شوید که پیام های خطای ساده و عمومی به کاربران ارائه می شود که آنها را با جزئیات فنی سردرگم نمی کند، یا بدتر از آن، اطلاعات خصوصی در مورد سایت شما را که می تواند برای مهاجمان و هکر ها مفید باشد را در اختیار کاربران قرار نمی دهید.