হ্যাকিং ছাড়াই ওয়েবসাইটের নিরাপত্তা যাচাই করার উপায়

অনলাইন স্টোরের প্যাসিভ নিরাপত্তা চেক: TLS সার্টিফিকেটের মেয়াদ, HSTS, CSP, nosniff, কুকি ফ্ল্যাগ, মিক্সড কনটেন্ট, পুরোনো jQuery, security.txt ও DMARC।

FixReports সম্পাদকীয় দলহালনাগাদ: 22 অক্টোবর, 202610 মিনিটে পড়ুন

সাইটটি প্রত্যেক ভিজিটরকে এমনিতেই যা পাঠায় তা পড়ে আপনি বাইরে থেকেই একটি অনলাইন স্টোরের নিরাপত্তা সেটআপের অনেকখানি যাচাই করতে পারেন: এর TLS সার্টিফিকেট, রিডাইরেক্ট, HTTP রেসপন্স হেডার, কুকি, লোড হওয়া স্ক্রিপ্ট এবং পাবলিক DNS রেকর্ড। এই প্যাসিভ চেকগুলো কোনো আক্রমণাত্মক ট্রাফিক পাঠায় না এবং কোনো লগইন লাগে না, তাই স্টোরের ওপর একটি সাধারণ ভিজিটের চেয়ে বেশি চাপ পড়ে না। এগুলো কনফিগারেশনের ফাঁকফোকর ধরে, যেমন মেয়াদ ফুরিয়ে আসা সার্টিফিকেট, HSTS না থাকা, অনিরাপদ কুকি, মিক্সড কনটেন্ট বা জানা ত্রুটিসহ কোনো jQuery সংস্করণ। এগুলো পেনিট্রেশন টেস্ট নয়, এবং কোনো স্টোর নিরাপদ বলে প্রমাণ করতে পারে না।

মূল বিষয়গুলো

15 মার্চ 2026 থেকে ইস্যু করা পাবলিকলি ট্রাস্টেড TLS সার্টিফিকেটের মেয়াদ সর্বোচ্চ 200 দিন হতে পারে; মার্চ 2027-এ তা নেমে আসবে 100 দিনে এবং মার্চ 2029-এ 47 দিনে (CA/Browser Forum (নতুন ট্যাবে খোলে))।
সাধারণ HTTP দিয়ে পাঠানো হলে ব্রাউজার HSTS হেডার উপেক্ষা করে (MDN (নতুন ট্যাবে খোলে))।
CSP-র frame-ancestors নির্দেশনা <meta> ট্যাগে কাজ করে না; এটিকে রেসপন্স হেডার হিসেবেই পাঠাতে হয় (MDN (নতুন ট্যাবে খোলে))।
3.5.0-এর আগের jQuery সংস্করণগুলো দুটি XSS দুর্বলতায় আক্রান্ত, এবং CISA এর একটি, CVE-2020-11023, 23 জানুয়ারি 2025-এ তার Known Exploited Vulnerabilities ক্যাটালগে যোগ করেছে (NVD (নতুন ট্যাবে খোলে))।
একটি security.txt ফাইলে অবশ্যই Contact ও Expires ফিল্ড থাকতে হবে এবং এটি /.well-known/security.txt-এ রাখতে হবে (RFC 9116 (নতুন ট্যাবে খোলে))।

প্যাসিভ নিরাপত্তা চেক বলতে কী বোঝায়?

প্যাসিভ চেক কেবল সেটুকুই পড়ে, যা একটি সাধারণ রিকোয়েস্টের জবাবে সাইট বা তার DNS ফেরত দেয়।

এর মানে পাবলিক পেজ লোড করা, সার্টিফিকেট ও রেসপন্স হেডার পড়া, একটি পেজ কোন কোন কুকি ও স্ক্রিপ্ট সেট করে তার তালিকা করা, এবং পাবলিক DNS রেকর্ড কোয়েরি করা। প্যাসিভ চেক পাসওয়ার্ড অনুমান করে না, ইনজেকশন পেলোড পাঠায় না, অ্যাডমিন URL খুঁজে বেড়ায় না বা পোর্ট স্ক্যান করে না। নিচের সবকিছুই একটি ব্রাউজার, curl, openssl ও dig দিয়ে করা যায়।

TLS সার্টিফিকেট ও তার মেয়াদ কীভাবে যাচাই করবেন?

সার্টিফিকেটের তারিখ ও নামগুলো সরাসরি পড়ুন, এবং নিশ্চিত করুন যে নবায়ন স্বয়ংক্রিয়ভাবে হয়।

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

দেখে নিন notAfter তারিখটি যথেষ্ট দূরে আছে কি না, আপনি example.com ও www.example.com দুটিই ব্যবহার করলে সার্টিফিকেট দুটিকেই কভার করে কি না (ব্রাউজারের সার্টিফিকেট ভিউয়ারে নামগুলো দেখা যায়), এবং ব্রাউজার কোনো সতর্কবার্তা দেখায় কি না। 11 এপ্রিল 2025-এ গৃহীত Ballot SC-081v3 (নতুন ট্যাবে খোলে) অনুসারে CA/Browser Forum Baseline Requirements (সেকশন 6.3.2, অক্টোবর 2026 অনুযায়ী সংস্করণ 2.3.1) সার্টিফিকেটের মেয়াদ ধাপে ধাপে কমিয়ে আনছে:

সার্টিফিকেট ইস্যুর সময়	সর্বোচ্চ মেয়াদ
15 মার্চ 2026-এর আগে	398 দিন
15 মার্চ 2026 থেকে 14 মার্চ 2027	200 দিন
15 মার্চ 2027 থেকে 14 মার্চ 2029	100 দিন
15 মার্চ 2029 থেকে	47 দিন

মেয়াদ কম হলে হাতে হাতে নবায়ন করা ঝুঁকিপূর্ণ, তাই নিশ্চিত হয়ে নিন যে আপনার হোস্ট বা সার্টিফিকেট টুল স্বয়ংক্রিয়ভাবে নবায়ন করে। সেই সঙ্গে নিশ্চিত করুন যে সাধারণ HTTP থেকে HTTPS-এ রিডাইরেক্ট হয়:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

আপনার দরকার একটি 301 (বা 308) রেসপন্স, যার location হেডার https:// দিয়ে শুরু।

একটি অনলাইন স্টোরের কোন কোন সিকিউরিটি হেডার পাঠানো উচিত?

অল্প কয়েকটি রেসপন্স হেডার প্রায় বিনা খরচে ব্রাউজার-পর্যায়ের প্রচলিত আক্রমণ ঠেকায়।

হেডার	কী করে	সাধারণ মান	সূত্র
`Strict-Transport-Security`	ব্রাউজারকে কেবল HTTPS ব্যবহার করতে বলে এবং ব্যবহারকারীকে সার্টিফিকেট এরর উপেক্ষা করে এগিয়ে যেতে দেয় না	`max-age=31536000; includeSubDomains`	MDN (নতুন ট্যাবে খোলে)
`Content-Security-Policy: frame-ancestors`	কোন কোন সাইট আপনার পেজ এমবেড করতে পারবে তা নিয়ন্ত্রণ করে, যা ক্লিকজ্যাকিং থেকে রক্ষা করে	`frame-ancestors 'self'`	MDN (নতুন ট্যাবে খোলে)
`X-Frame-Options`	ফ্রেমিং নিয়ন্ত্রণের পুরোনো পদ্ধতি; OWASP বলে, যেসব ব্রাউজার `frame-ancestors` সমর্থন করে সেগুলোতে এটি অপ্রচলিত	`DENY` বা `SAMEORIGIN`	OWASP (নতুন ট্যাবে খোলে)
`X-Content-Type-Options`	MIME sniffing বন্ধ করে এবং ভুল টাইপে পাঠানো স্ক্রিপ্ট ও স্টাইলশিট ব্লক করে	`nosniff`	MDN (নতুন ট্যাবে খোলে)
`Referrer-Policy`	আপনার URL-এর কতটুকু অন্য সাইটে পাঠানো হবে তা সীমিত করে	`strict-origin-when-cross-origin`	OWASP
`X-XSS-Protection`	ব্রাউজারের XSS ফিল্টার হেডার; OWASP বলে এটি অন্যথায় নিরাপদ সাইটেও XSS দুর্বলতা তৈরি করতে পারে	সেট করবেন না, অথবা `0`	OWASP

আপনার স্টোর কী পাঠাচ্ছে তা দেখুন:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

দুটি সতর্কতা। includeSubDomains এমন যেকোনো সাবডোমেইন আটকে দেয় যা কেবল HTTP-তে চলে, তাই আগে সাবডোমেইনগুলো যাচাই করুন। HSTS preload-এর জন্য অন্তত 31536000-এর max-age এবং includeSubDomains লাগে, তাই প্রতিটি সাবডোমেইন HTTPS-এর জন্য তৈরি হলে তবেই preload যোগ করুন। স্ক্রিপ্ট সীমিত করে এমন একটি পূর্ণাঙ্গ CSP রাখা লাভজনক, তবে OWASP উল্লেখ করে যে এটি কনফিগার ও রক্ষণাবেক্ষণ করা জটিল, এবং অনেক অ্যাপ ব্যবহার করা স্টোরকে এটি সাবধানে পরীক্ষা করতে হবে।

আপনার কুকিগুলো কি Secure, HttpOnly ও SameSite দিয়ে সেট করা?

সেশন ও কার্টের কুকিতে তিনটি অ্যাট্রিবিউটই থাকা উচিত, এবং Set-Cookie রেসপন্স হেডারে আপনি সেগুলো দেখতে পাবেন।

অ্যাট্রিবিউট	প্রভাব (MDN (নতুন ট্যাবে খোলে) অনুযায়ী)	কোথায় গুরুত্বপূর্ণ
`Secure`	কেবল HTTPS দিয়ে পাঠানো হয়; সাধারণ HTTP-তে চলা সাইট এটি সেট করতে পারে না	HTTPS স্টোরের প্রতিটি কুকি
`HttpOnly`	JavaScript `document.cookie` দিয়ে এটি পড়তে পারে না, যা XSS-এর বিরুদ্ধে সাহায্য করে	লগইন সেশন ও কার্ট
`SameSite=Lax` বা `Strict`	ক্রস-সাইট রিকোয়েস্টে কুকি কখন পাঠানো হবে তা সীমিত করে	সেশন; অথেনটিকেশন ও কার্ট কুকির জন্য `Strict` উপযুক্ত
`SameSite=None`	ক্রস-সাইট রিকোয়েস্টে পাঠানো হয়; অবশ্যই `Secure`-এর সঙ্গে ব্যবহার করতে হবে	কেবল সেইসব এমবেড করা থার্ড-পার্টি ফিচার, যেগুলোর এটি দরকার

কোনো SameSite অ্যাট্রিবিউট সেট করা না থাকলে ব্রাউজার কুকিটিকে Lax হিসেবে গণ্য করে। যেসব কুকি আপনার নিজের স্ক্রিপ্টকে পড়তে হয় সেগুলো HttpOnly হতে পারে না, তাই লগইন করা গ্রাহক বা অ্যাডমিনকে শনাক্ত করে এমন কুকিগুলোর দিকে মনোযোগ দিন।

curl -sI https://example.com/ | grep -i "^set-cookie"

ব্রাউজারের ডেভেলপার টুলেও একই তথ্য দেখা যায়, পেজ লোডের পর স্ক্রিপ্ট যেসব কুকি সেট করে সেগুলোসহ।

মিক্সড কনটেন্ট কীভাবে খুঁজে বের করবেন?

HTTPS-এ পরিবেশিত কোনো পেজে HTTP দিয়ে লোড হওয়া যেকোনো রিসোর্সই মিক্সড কনটেন্ট, এবং ব্রাউজারের কনসোলে এর তালিকা দেখা যায়।

MDN (নতুন ট্যাবে খোলে) একে দুই ভাগে ভাগ করে। ছবি, অডিও ও ভিডিও “upgradable”: ব্রাউজার স্বয়ংক্রিয়ভাবে এগুলো HTTPS দিয়ে চায়। স্ক্রিপ্ট, স্টাইলশিট, iframe, ফন্ট ও fetch() রিকোয়েস্ট “blockable”: ব্রাউজার এগুলো ব্লক করে দেয়, ফলে এগুলোর ওপর নির্ভরশীল সবকিছু ভেঙে যায়। শুধু IP ঠিকানায় যাওয়া আপগ্রেড করা রিকোয়েস্টও ব্লক হয়।

এটি খুঁজতে আপনার মূল টেমপ্লেটগুলোতে (হোম, কালেকশন, প্রোডাক্ট, কার্ট) কনসোল খুলুন, এবং থিমের কোড, পেজের কনটেন্ট ও অ্যাপ সেটিংসে http:// সার্চ করুন। Shopify-এর হেল্প সেন্টার বলে, HTTPS দিয়ে পরিবেশিত নয় এমন কোনো অ্যাসেট থাকা স্টোরের যেকোনো পেজ অনিরাপদ বলে গণ্য হয় (নতুন ট্যাবে খোলে), এবং অ্যাসেটগুলো Shopify-তে হোস্ট করার বা HTTPS দিয়ে পরিবেশন করার সুপারিশ করে। WooCommerce-এ, সাইটটি কখনো http://-এ চলে থাকলে পুরোনো পোস্টের কনটেন্ট ও থিম অপশন যাচাই করুন।

জানা CVE-সহ পুরোনো JavaScript লাইব্রেরি কীভাবে চিনবেন?

প্রতিটি পেজ কোন কোন লাইব্রেরি লোড করে তার তালিকা করুন, সেগুলোর সংস্করণ পড়ুন, এবং National Vulnerability Database-এর সঙ্গে মিলিয়ে দেখুন।

jQuery দিয়ে শুরু করুন। ব্রাউজারের কনসোলে $.fn.jquery লোড হওয়া সংস্করণটি দেখায় (jQuery API (নতুন ট্যাবে খোলে))। যেসব সংস্করণ চিহ্নিত করবেন:

CVE	আক্রান্ত সংস্করণ	সমস্যা	NVD স্কোর (v3.1)
CVE-2020-11022 (নতুন ট্যাবে খোলে)	1.12.0 থেকে 3.5.0-এর আগ পর্যন্ত	`.html()` বা `.append()`-এর মতো মেথডে অবিশ্বস্ত HTML দিলে কোড চলতে পারে	6.1 Medium
CVE-2020-11023 (নতুন ট্যাবে খোলে)	1.0.3 থেকে 3.5.0-এর আগ পর্যন্ত	একই সমস্যা, `<option>` এলিমেন্ট থাকা HTML-এর ক্ষেত্রে; 23 জানুয়ারি 2025 থেকে CISA-র KEV ক্যাটালগে	6.1 Medium
CVE-2019-11358 (নতুন ট্যাবে খোলে)	3.4.0-এর আগের সব	`jQuery.extend(true, ...)`-এর মাধ্যমে prototype pollution	6.1 Medium

2020 সালের দুটি সমস্যাই jQuery 3.5.0-এ ঠিক করা হয়েছে। দুর্বল সংস্করণ থাকার মানে ত্রুটিপূর্ণ কোডটি উপস্থিত আছে; এর অপব্যবহার করা যাবে কি না তা নির্ভর করে সাইট কীভাবে এতে ডেটা পাঠায় তার ওপর। WordPress 5.6 সংস্করণ থেকে (নতুন ট্যাবে খোলে) jQuery 3.5.1 সঙ্গে দেয়, তাই WooCommerce স্টোরে পুরোনো jQuery থাকা মানে হয় WordPress পুরোনো, নয়তো কোনো থিম বা প্লাগইন নিজস্ব কপি লোড করছে। Shopify-তে আপনার থিম ফাইল এবং স্ক্রিপ্ট যোগ করা অ্যাপগুলো যাচাই করুন।

security.txt কী, এবং আপনার স্টোরে কি এটি দরকার?

এটি একটি সাধারণ টেক্সট ফাইল, যা নিরাপত্তা গবেষকদের জানায় কীভাবে আপনাকে কোনো দুর্বলতার খবর দেবেন।

RFC 9116 (নতুন ট্যাবে খোলে) (এপ্রিল 2022, একটি Informational RFC, তাই এটি মেনে চলা ঐচ্ছিক) বলে ফাইলটি HTTPS দিয়ে /.well-known/security.txt-এ text/plain হিসেবে পরিবেশন করতে হবে। Contact ও Expires বাধ্যতামূলক, এবং RFC এক বছরের কম সময় পরের একটি Expires তারিখ সুপারিশ করে।

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

WooCommerce-এ আপনি ফাইলটি নিজের সার্ভারে রাখতে পারেন। হোস্টেড প্ল্যাটফর্মে দেখে নিন ওই পাথে ফাইল প্রকাশ করা যায় কি না; না গেলেও, আপনার যোগাযোগ পেজে স্পষ্টভাবে চিহ্নিত একটি নিরাপত্তা-যোগাযোগের ঠিকানা কাজে আসে।

DMARC কীভাবে আপনার স্টোরকে ইমেইল স্পুফিং থেকে রক্ষা করে?

From ঠিকানায় আপনার ডোমেইন ব্যবহার করে অথচ অ্যালাইনড SPF বা DKIM পাস করে না এমন মেইল কোয়ারেন্টিন বা প্রত্যাখ্যান করতে DMARC দিয়ে আপনি মেইলবক্স প্রোভাইডারদের অনুরোধ জানাতে পারেন।

p=none রেকর্ড কেবল রিপোর্ট সংগ্রহ করে; এটি স্পুফ করা মেইল থামায় না। গ্রাহকেরা আপনার ডোমেইন থেকে অর্ডার কনফার্মেশন ও পাসওয়ার্ড রিসেটের মেইল আশা করেন, তাই হুবহু আপনার ডোমেইন দেখানো ফিশিং বার্তা আটকানো জরুরি। dig +short TXT _dmarc.example.com দিয়ে আপনার নীতি যাচাই করুন, এবং স্পেসিফিকেশনের জন্য RFC 9989 (নতুন ট্যাবে খোলে) দেখুন। DMARC দেখতে একই রকম অন্য ডোমেইনকে কভার করে না, কেবল সেই ডোমেইনকে কভার করে যেটি রেকর্ডটি প্রকাশ করে।

Shopify কী সামলায়, আর WooCommerce-এ আপনি কী নিয়ন্ত্রণ করেন?

Shopify তার স্টোরফ্রন্টের পেছনের সার্ভারগুলো চালায়, আর সেলফ-হোস্টেড WooCommerce স্টোরে সার্ভারের সেটিং আপনার ও আপনার হোস্টের দায়িত্বে।

চেক	Shopify	WooCommerce (সেলফ-হোস্টেড)
TLS সার্টিফিকেট	Shopify-তে যোগ করা সব ডোমেইনের জন্য বিনামূল্যে (নতুন ট্যাবে খোলে); থার্ড-পার্টি ডোমেইনের ক্ষেত্রে 48 ঘণ্টা পর্যন্ত লাগতে পারে	আপনার হোস্ট বা আপনার নিজের সেটআপ
HTTP থেকে HTTPS রিডাইরেক্ট	প্ল্যাটফর্ম	ওয়েব সার্ভার, CDN বা হোস্টের সেটিং
সিকিউরিটি হেডার	Shopify-এর সার্ভার পাঠায়	ওয়েব সার্ভার, CDN বা একটি প্লাগইন
কুকি ফ্ল্যাগ	Shopify-এর নিজস্ব কুকি প্ল্যাটফর্ম সেট করে; অ্যাপ ও থিমের কুকি আপনার দায়িত্ব	WordPress core, প্লাগইন ও সার্ভার
মিক্সড কনটেন্ট ও JS লাইব্রেরি	আপনার থিম, কনটেন্ট ও অ্যাপ	আপনার থিম, কনটেন্ট ও প্লাগইন
security.txt ও DMARC	আপনার ডোমেইন ও DNS	আপনার ডোমেইন ও DNS

অক্টোবর 2026-এ আমরা Shopify-তে হোস্ট করা কয়েকটি স্টোরফ্রন্ট যাচাই করে দেখেছি, সেগুলোর রেসপন্সে প্রায় 91 দিনের max-age-সহ HSTS, X-Content-Type-Options: nosniff এবং upgrade-insecure-requests-সহ একটি CSP ছিল, তবে frame-ancestors স্টোরভেদে আলাদা ছিল। Shopify বলে এটি Level 1 PCI DSS compliant হিসেবে সার্টিফায়েড (নতুন ট্যাবে খোলে)। আপনার থিম ও ইনস্টল করা অ্যাপের দায়িত্ব আপনারই থাকে।

WooCommerce-এর ক্ষেত্রে WordPress-এর hardening গাইড (নতুন ট্যাবে খোলে) বলে WordPress ও প্লাগইন হালনাগাদ রাখতে, ব্যবহার না করা প্লাগইন মুছে ফেলতে, এবং আপনার হোস্ট কী কী নিরাপত্তা ব্যবস্থা নেয় তা তাদের কাছে জিজ্ঞেস করতে।

কেন এটি পেনিট্রেশন টেস্ট নয়?

পেনিট্রেশন টেস্ট সক্রিয়ভাবে আক্রমণের চেষ্টা করে; প্যাসিভ চেক কেবল পর্যবেক্ষণ করে।

NIST SP 800-115 পেনিট্রেশন টেস্টিংকে এমন নিরাপত্তা পরীক্ষা হিসেবে সংজ্ঞায়িত করে, যেখানে মূল্যায়নকারীরা বাস্তব আক্রমণের অনুকরণ করে কোনো সিস্টেমের নিরাপত্তা ব্যবস্থা এড়িয়ে যাওয়ার উপায় খোঁজেন (NIST glossary (নতুন ট্যাবে খোলে))। প্যাসিভ চেক প্লাগইনের সার্ভার-সাইড ত্রুটি, দুর্বল বা একাধিক জায়গায় ব্যবহৃত অ্যাডমিন পাসওয়ার্ড, টু-ফ্যাক্টর অথেনটিকেশন না থাকা, ভাঙা অ্যাক্সেস কন্ট্রোল বা পেজের সোর্সে কখনো দেখা যায় না এমন দুর্বল কোড দেখতে পায় না। এগুলোকে একটি ভিত্তিরেখা হিসেবে ব্যবহার করুন, যা যেকোনো সময় আবার চালানো যায়। আরও গভীর নিশ্চয়তার জন্য লিখিত পরিধি (scope) ঠিক করে একটি পেনিট্রেশন টেস্ট করান, এমন সিস্টেমে যার মালিক আপনি অথবা যা পরীক্ষার অনুমতি আপনার আছে।

একটি বিনামূল্যের স্ক্যান আপনার স্টোরের একটি প্রাথমিক যাচাই চালায়। ওয়েবসাইট নিরাপত্তা রিপোর্ট এই লেখার প্যাসিভ চেকগুলো কভার করে, TLS ও রিডাইরেক্ট থেকে শুরু করে হেডার, কুকি, মিক্সড কনটেন্ট, পুরোনো লাইব্রেরি, security.txt ও DMARC পর্যন্ত, প্রতিটি ফলাফলের জন্য সমাধানসহ। যেকোনো প্যাসিভ পর্যালোচনার মতোই, এটি কোনো স্টোর নিরাপদ হওয়ার নিশ্চয়তা দিতে পারে না।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

প্যাসিভ নিরাপত্তা চেক কি আমার স্টোরকে ঝুঁকিতে ফেলে?

একটি সাধারণ ভিজিটের চেয়ে বেশি নয়। এগুলো সেই একই পাবলিক পেজ ও DNS রেকর্ড চায় যা যেকোনো ব্রাউজার বা মেইল সার্ভার চাইত, এবং লগইনের চেষ্টা করে না বা আক্রমণের পেলোড পাঠায় না।

Shopify-তে কি সিকিউরিটি হেডার যোগ করা যায়?

স্টোরফ্রন্টের রেসপন্স হেডার আসে Shopify-এর সার্ভার থেকে, তাই আপনার দরকারি কোনো হেডার না থাকলে Shopify Support-এর সঙ্গে যোগাযোগ করুন। আপনার থিমে একটি CSP <meta> ট্যাগ কিছু নির্দেশনা যোগ করতে পারে, তবে MDN উল্লেখ করে যে <meta>-তে frame-ancestors সমর্থিত নয়।

পুরোনো jQuery সংস্করণ থাকা মানে কি আমার স্টোর হ্যাক হয়েছে?

না। এর মানে জানা দুর্বলতাসহ কোড লোড হচ্ছে, যা ঝুঁকি বাড়ায় যদি সাইট আক্রান্ত মেথডগুলোতে অবিশ্বস্ত HTML পাঠায়। এটি হালনাগাদ করুন, অথবা যে থিম বা প্লাগইন এটি লোড করে সেটি সরিয়ে ফেলুন।

এখন একটি TLS সার্টিফিকেটের মেয়াদ সর্বোচ্চ কত দিন হতে পারে?

15 মার্চ 2026 থেকে ইস্যু করা পাবলিকলি ট্রাস্টেড সার্টিফিকেটের মেয়াদ সর্বোচ্চ 200 দিন হতে পারে। 15 মার্চ 2027 থেকে এই সীমা নেমে আসবে 100 দিনে, এবং 15 মার্চ 2029 থেকে 47 দিনে।

security.txt ফাইল কি বাধ্যতামূলক?

RFC 9116 একটি Informational RFC, তাই এই স্ট্যান্ডার্ড অনুযায়ী ফাইলটি প্রকাশ করা ঐচ্ছিক। এটি প্রকাশ করতে খরচ সামান্য, এবং এটি গবেষকদের আপনার সঙ্গে যোগাযোগের একটি স্পষ্ট পথ দেয়।

প্যাসিভ স্ক্যানে কোনো সমস্যা না পাওয়া মানে কি আমার স্টোর নিরাপদ?

না। এটি কেবল দেখায় যে পাবলিক কনফিগারেশন ঠিক আছে বলে মনে হচ্ছে। সার্ভার-সাইড দুর্বলতা, অ্যাকাউন্টের নিরাপত্তা এবং বিজনেস লজিকের ত্রুটির জন্য অন্য ধরনের পরীক্ষা লাগে।

তথ্যসূত্র

Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.3.1 (নতুন ট্যাবে খোলে), CA/Browser Forum, 4 অক্টোবর 2026
Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (নতুন ট্যাবে খোলে), CA/Browser Forum, 11 এপ্রিল 2025
Strict-Transport-Security (নতুন ট্যাবে খোলে), MDN Web Docs, সর্বশেষ পরিবর্তন 11 সেপ্টেম্বর 2026
CSP: frame-ancestors (নতুন ট্যাবে খোলে), MDN Web Docs, সর্বশেষ পরিবর্তন 27 আগস্ট 2026
X-Content-Type-Options (নতুন ট্যাবে খোলে), MDN Web Docs, সর্বশেষ পরিবর্তন 17 মার্চ 2026
Using HTTP cookies (নতুন ট্যাবে খোলে), MDN Web Docs, সর্বশেষ পরিবর্তন 17 সেপ্টেম্বর 2026
Mixed content (নতুন ট্যাবে খোলে), MDN Web Docs, সর্বশেষ পরিবর্তন 15 আগস্ট 2026
HTTP Security Response Headers Cheat Sheet (নতুন ট্যাবে খোলে), OWASP Cheat Sheet Series, দেখা হয়েছে 22 অক্টোবর 2026
CVE-2020-11022 (নতুন ট্যাবে খোলে), NIST National Vulnerability Database, প্রকাশিত 29 এপ্রিল 2020
CVE-2020-11023 (নতুন ট্যাবে খোলে), NIST National Vulnerability Database, প্রকাশিত 29 এপ্রিল 2020
CVE-2019-11358 (নতুন ট্যাবে খোলে), NIST National Vulnerability Database, প্রকাশিত 20 এপ্রিল 2019
.jquery (নতুন ট্যাবে খোলে), jQuery API Documentation, দেখা হয়েছে 22 অক্টোবর 2026
Updating core jQuery to version 3, part 2 (নতুন ট্যাবে খোলে), Make WordPress Core, 5 নভেম্বর 2020
RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (নতুন ট্যাবে খোলে), IETF, এপ্রিল 2022
RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (নতুন ট্যাবে খোলে), IETF, মে 2026
Enabling secure connections to your Shopify store (নতুন ট্যাবে খোলে), Shopify Help Center, দেখা হয়েছে 22 অক্টোবর 2026
Security (নতুন ট্যাবে খোলে), Shopify, দেখা হয়েছে 22 অক্টোবর 2026
Hardening WordPress (নতুন ট্যাবে খোলে), WordPress Developer Resources, দেখা হয়েছে 22 অক্টোবর 2026
Penetration testing (glossary) (নতুন ট্যাবে খোলে), NIST Computer Security Resource Center, NIST SP 800-115 (সেপ্টেম্বর 2008) উদ্ধৃত করে, দেখা হয়েছে 22 অক্টোবর 2026