اعتبارسنجی فرم: مرورگر، سرور یا هر دو؟
مرورگر برای بازخورد سریع، سرور برای قاعدهٔ واقعی. جدول «کدام بررسی کجا» بر پایهٔ MDN، OWASP و WCAG برای تجربهٔ خطا و امنیت ورودی.
SE
4 min readSoheil Ebrahimpour
Founder & product engineer
«اعتبارسنجی در مرورگر کافی است؟» پاسخ کوتاه: نه. مرورگر برای راحتی کاربر است و سرور برای درستی داده و امنیت. این مقاله دو هدف را جدا می‌کند و جدول «کدام بررسی کجا» می‌دهد. مبانی طراحی فرم در فرم‌های خوب چگونه طراحی می‌شوند؟ آمده و اینجا فقط جایگاه فنی بررسی‌ها را می‌گوییم.
دو هدف جدا
MDN می‌گوید اعتبارسنجی سمت کلاینت بررسی اولیه و بخش مهمی از تجربهٔ کاربری خوب است چون کاربر بلافاصله می‌تواند خطا را اصلاح کند، بدون رفت‌وبرگشت به سرور. در همان صفحه تأکید می‌شود این بررسی را نباید اقدام امنیتی کامل دانست و روی سرور هم باید اعتبارسنجی، از جمله بررسی امنیتی، انجام شود چون دور زدن سمت کلاینت آسان است. OWASP هم در بخش خطاهای رایج می‌نویسد «بررسی فقط سمت کلاینت» خطاست: حتی اگر مرورگر همان فیلدها را بررسی می‌کند، سرور هم باید بررسی کند و سمت کلاینت برای بازخورد فوری است.
کدام بررسی کجا؟
| بررسی | مرورگر | سرور |
|---|---|---|
| فیلد اجباری خالی نباشد | بله، برای بازخورد سریع | بله، قاعدهٔ اصلی |
| قالب (ایمیل، تلفن، تاریخ) | بله، قالب ساده | بله، با قاعدهٔ دقیق |
| محدودهٔ مقدار و طول | اختیاری | الزامی |
| یکتایی (ایمیل تکراری) | فقط راهنما | الزامی |
| مجوز کاربر برای این عملیات | نه | الزامی |
| قواعد کسب‌وکار (موجودی، سقف) | راهنما | الزامی |
در مرورگر: HTML پیش از JavaScript
MDN توضیح می‌دهد HTML با attributeهای اعتبارسنجی می‌تواند فیلد ضروری و قالب معتبر را بدون JavaScript تعیین کند و اعتبارسنجی HTML سریع‌تر از JavaScript است؛ JavaScript معمولاً برای بهبود یا سفارشی‌سازی همان می‌آید. پس مسیر پیشنهادی: اول attributeهای استاندارد، بعد پیام‌های سفارشی.
در سرور: قاعدهٔ واقعی
OWASP چند نکتهٔ دقیق دارد که ارزش دارد در بازبینی کد بپرسید: تبدیل متن به عدد فقط نوع را مشخص می‌کند و مقدار قابل‌قبول را نه؛ حذف یا «تمیزکردن» کاراکترهای مشکوک جای تعریف قاعدهٔ پذیرش هر فیلد را نمی‌گیرد (مثلاً بستن آپوستروف نام‌های معتبر را رد می‌کند بی‌آنکه کوئری را ایمن کند)؛ اعتبارسنجی قالب ایمیل دسترسی به صندوق را اثبات نمی‌کند؛ و برای متن آزاد می‌توان یونیکد گسترده را با محدودیت طول پذیرفت و لازم نیست فقط حرف و عدد مجاز باشد. این آخری برای متن فارسی مهم است: قاعدهٔ «فقط حروف انگلیسی» نام‌های فارسی را رد می‌کند.
پیام خطا
معیار 3.3.1 در WCAG 2.2 (سطح A) می‌گوید اگر خطای ورودی خودکار تشخیص داده شود، آیتم خطادار شناسایی و خطا به‌صورت متن توصیف شود و فقط نمایش دوبارهٔ فرم کافی نیست. معیار 3.3.3 (سطح AA) اضافه می‌کند اگر راه اصلاح شناخته‌شده است باید پیشنهاد داده شود، مگر امنیت یا هدف محتوا را به خطر بیندازد. مثال: «ایمیل باید @ داشته باشد، مثل name@example.com» بهتر از «ورودی نامعتبر» است.
اشتباه‌های رایج
- اعتماد به مرورگر و حذف بررسی سرور.
- پیام کلی «خطا» بدون اینکه بگوید کدام فیلد و چه چیزی.
- تکیه بر رنگ برای نمایش خطا؛ متن لازم است.
- رد کردن ورودی معتبر فارسی با قاعدهٔ لاتین.
- تصور اینکه تأیید قالب ایمیل یعنی ایمیل واقعی است.
برای تعریف «آمادهٔ تولید»، Production-Ready را ببینید. اگر می‌خواهید فرم‌های محصولتان را با یک تیم بازبینی کنید، صفحهٔ شروع پروژه را ببینید؛ ارسال فرم تعهدی ایجاد نمی‌کند.
منابع و مراجع
- Client-side form validation — MDN Web Docs (Mozilla).
- Input Validation Cheat Sheet — OWASP Cheat Sheet Series.
- Understanding Success Criterion 3.3.1: Error Identification (WCAG 2.2) — W3C WAI، WCAG 2.2.
- Understanding Success Criterion 3.3.3: Error Suggestion (WCAG 2.2) — W3C WAI، WCAG 2.2.
Author
SE
Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.
Related notes
If you are unsure about architecture or the build path, we can talk about the project.
Describe the problem and the constraints. If there is a fit, we will schedule a conversation.
