Contact form-এ spam বাড়লে genuine enquiry হারায়, email reputation নষ্ট হয় এবং database অপ্রয়োজনীয় data-য় ভরে যায়। শুধু CAPTCHA বসালেই স্থায়ী সমাধান হয় না; কঠিন challenge real user ও accessibility-কে বাধা দিতে পারে, আবার automated attacker সেটি এড়িয়েও যেতে পারে। ভালো protection কয়েকটি ছোট layer ব্যবহার করে—server-side validation, request limit, behaviour signal, safe storage এবং useful monitoring।
Server-side validation বাধ্যতামূলক
Browser-এর required, maxlength বা input type user experience উন্নত করে, security boundary নয়। Server-এ প্রত্যেক field-এর type, length, allowed format ও required state validate করুন। Unknown field ignore বা reject করুন। Email format check করলেও mailbox সত্যি কি না ধরে নেবেন না। HTML দরকার না হলে plain text হিসেবে store করুন; output-এর context অনুযায়ী escape করুন। SQL query parameter binding দিয়ে চালান।
CSRF ও authentication আলাদা সমস্যা
CSRF token legitimate browser session থেকে unwanted submission আটকায়, internet bot-কে একা থামায় না। Logged-in form-এ central CSRF protection ব্যবহার করুন এবং token failure log-এ raw token রাখবেন না। Public form-এ rate limit, session/cookie signal এবং request timing বেশি কার্যকর। Admin action কখনো public enquiry endpoint-এর সঙ্গে মেশাবেন না।
Honeypot ও timing signal
Visually hidden কিন্তু bot-এর কাছে visible একটি non-essential field রাখতে পারেন; field পূরণ হলে silently quarantine করুন। Screen reader যেন confusing label না পায় এবং keyboard focus যেন সেখানে না যায়। Form page load-এর কয়েক millisecond-এর মধ্যে submit হলে suspicious signal হতে পারে, তবে slow/fast user-কে শুধু timing দেখে block করবেন না। একাধিক signal score করে threshold নিন।
Rate limit design
শুধু IP block করলে office, mobile carrier বা shared network-এর genuine user ক্ষতিগ্রস্ত হতে পারেন। IP-এর privacy-preserving hash, session, form, account এবং time window মিলিয়ে limit দিন। Short burst এবং daily volume আলাদা রাখুন। Limit হলে 429 status, retry guidance এবং accessible message দিন। Raw IP দীর্ঘদিন log করবেন না; retention minimum রাখুন।
Email ও storage নিরাপদ রাখুন
User-supplied subject দিয়ে mail header বানাবেন না। Fixed sender domain ব্যবহার করে Reply-To validation করুন। Attachment দরকার না হলে upload বন্ধ রাখুন। দরকার হলে allowlisted MIME, size, image decoding এবং isolated storage ব্যবহার করুন; executable বা SVG নেবেন না। Spam entry সরাসরি team inbox-এ না পাঠিয়ে queue বা digest-এ নিলে mail flood কমে।
১০টি practical check
- সব field server-side validate করুন।
- Output escape ও parameterised SQL ব্যবহার করুন।
- State-changing form-এ CSRF দিন।
- Accessible honeypot implementation test করুন।
- IP ছাড়াও session ও form-based rate limit দিন।
- Mail header injection আটকান।
- Upload প্রয়োজন না হলে বন্ধ রাখুন।
- Suspicious entry quarantine করুন।
- False positive sample review করুন।
- Volume, failure ও delivery alert রাখুন।
Protection launch করার পরে genuine submit success rate, spam count, support complaint ও average completion time দেখুন। Spam শূন্য করাই লক্ষ্য নয়; genuine visitor যেন সহজে message পাঠাতে পারেন, সেটি equally important।
কাজ শুরু করার আগে ছোট baseline নিন
ভালো guide শুধু কী করতে হবে বলে না; কেন করছেন এবং কাজটি সত্যিই ফল দিল কি না সেটাও পরিষ্কার করে। তাই শুরুতে বর্তমান সমস্যা, যাঁরা প্রভাবিত হচ্ছেন, expected result এবং acceptable risk লিখে নিন। অনুমানকে evidence ভাববেন না। Setting-এর নাম, official documentation, test result, screenshot বা export-এর মতো যাচাইযোগ্য তথ্য রাখুন। Personal data, password, OTP, API key বা client document দিয়ে test না করে anonymised sample ব্যবহার করুন।
ছোট ধাপে বদলান
একবারে সব change করলে কোন সিদ্ধান্তে সমস্যা হলো বোঝা কঠিন হয়। একটি ছোট reversible step নিন, result দেখুন, তারপর পরের step-এ যান। Production বা primary account বদলানোর আগে backup এবং rollback route সত্যিই কাজ করে কি না পরীক্ষা করুন। Team-এ owner ও backup owner ঠিক রাখুন। কোনো external vendor জড়িত থাকলে cost, retention, export, deletion এবং support policy পড়ুন; marketing promise-কে final evidence ধরবেন না।
Human review ও follow-up রাখুন
Automation, scanner বা AI দ্রুত signal দেয়, কিন্তু context ধরে final decision মানুষকেই নিতে হবে। Mobile network, বাংলা text, ভুল input, slow device এবং নতুন user দিয়ে practical task চালান। কাজ শেষে time saved, error, complaint, recovery এবং support request নোট করুন। এক সপ্তাহ পরে quick review এবং তিন মাস পরে deeper review রাখলে temporary fix স্থায়ী দুর্বলতায় বদলে যায় না। Result, owner, fallback এবং next review date এক জায়গায় লিখে রাখুন, যাতে handover-এর সময় আবার সব শূন্য থেকে বুঝতে না হয়।
Mobile form-এর usability ঠিক রাখতে mobile-first layout guide-এর touch target ও responsive input-এর নিয়ম মিলিয়ে নিন।
দ্রুত উত্তর
সাধারণ প্রশ্ন ও উত্তর
CAPTCHA কি সব form-এ লাগবে?
না। Low-friction validation, honeypot ও rate limit আগে দিন; attack volume বেশি হলে accessible CAPTCHA risk অনুযায়ী যোগ করুন।
সব step একদিনে করতে হবে?
না। সবচেয়ে বেশি risk-এর কাজ আগে নিন, ছোট reversible ধাপে এগোন এবং প্রতিটি result যাচাই করুন।
কখন আবার review করব?
Major change বা incident-এর পরে এবং অন্তত তিন মাস অন্তর owner, evidence, access ও recovery route review করুন।