হেডারগুলো সম্পর্কে আরও জানুন যা আপনার সাইটকে সুরক্ষিত রাখতে পারে এবং সবচেয়ে গুরুত্বপূর্ণ তথ্যগুলো দ্রুত খুঁজে পেতে সাহায্য করে।
এই নিবন্ধে আপনার ওয়েবসাইট সুরক্ষিত রাখতে ব্যবহারযোগ্য সবচেয়ে গুরুত্বপূর্ণ নিরাপত্তা হেডারগুলোর একটি তালিকা দেওয়া হয়েছে। ওয়েব-ভিত্তিক নিরাপত্তা বৈশিষ্ট্যগুলো বুঝতে, আপনার ওয়েবসাইটে সেগুলো কীভাবে প্রয়োগ করতে হয় তা শিখতে এবং প্রয়োজনের সময় মনে করিয়ে দেওয়ার জন্য এটিকে একটি সহায়ক উৎস হিসেবে ব্যবহার করুন।
- যেসব ওয়েবসাইট সংবেদনশীল ব্যবহারকারীর ডেটা পরিচালনা করে, তাদের জন্য প্রস্তাবিত নিরাপত্তা হেডার:
- বিষয়বস্তু নিরাপত্তা নীতি (সিএসপি)
- বিশ্বস্ত প্রকার
- সকল ওয়েবসাইটের জন্য প্রস্তাবিত নিরাপত্তা হেডার:
- X-কন্টেন্ট-টাইপ-অপশন
- এক্স-ফ্রেম-বিকল্প
- ক্রস-অরিজিন রিসোর্স পলিসি (CORP)
- ক্রস-অরিজিন ওপেনার পলিসি (COOP)
- HTTP কঠোর পরিবহন নিরাপত্তা (HSTS)
- উন্নত সক্ষমতা সম্পন্ন ওয়েবসাইটগুলির জন্য নিরাপত্তা হেডার:
- ক্রস-অরিজিন রিসোর্স শেয়ারিং (CORS)
- ক্রস-অরিজিন এমবেডার পলিসি (COEP)
সিকিউরিটি হেডার সম্পর্কে বিস্তারিত জানার আগে, ওয়েবের পরিচিত হুমকিগুলো এবং কেন এই সিকিউরিটি হেডারগুলো ব্যবহার করা প্রয়োজন, সে সম্পর্কে জেনে নিন।
ইনজেকশন দুর্বলতা থেকে আপনার সাইটকে সুরক্ষিত রাখুন
ইনজেকশন দুর্বলতা তখন দেখা দেয়, যখন আপনার অ্যাপ্লিকেশন দ্বারা প্রক্রিয়াকৃত অবিশ্বস্ত ডেটা এর আচরণকে প্রভাবিত করতে পারে এবং সাধারণত, আক্রমণকারী-নিয়ন্ত্রিত স্ক্রিপ্ট কার্যকর হওয়ার দিকে পরিচালিত করে। ইনজেকশন বাগের কারণে সৃষ্ট সবচেয়ে সাধারণ দুর্বলতা হলো ক্রস-সাইট স্ক্রিপ্টিং (XSS), যা এর বিভিন্ন রূপে বিদ্যমান; যেমন— রিফ্লেক্টেড XSS , স্টোর্ড XSS , DOM-ভিত্তিক XSS এবং এর অন্যান্য প্রকারভেদ।
একটি XSS দুর্বলতার মাধ্যমে সাধারণত একজন আক্রমণকারী অ্যাপ্লিকেশন দ্বারা প্রক্রিয়াকৃত ব্যবহারকারীর ডেটা এবং একই ওয়েব অরিজিনে হোস্ট করা অন্য যেকোনো তথ্যে সম্পূর্ণ অ্যাক্সেস পেতে পারে।
ইনজেকশনের বিরুদ্ধে প্রচলিত প্রতিরক্ষা ব্যবস্থাগুলোর মধ্যে রয়েছে অটো-এসকেপিং এইচটিএমএল টেমপ্লেট সিস্টেমের ধারাবাহিক ব্যবহার, বিপজ্জনক জাভাস্ক্রিপ্ট এপিআই ব্যবহার পরিহার করা, এবং ফাইল আপলোড একটি পৃথক ডোমেইনে হোস্ট করা ও ব্যবহারকারী-নিয়ন্ত্রিত এইচটিএমএল স্যানিটাইজ করার মাধ্যমে ব্যবহারকারীর ডেটা যথাযথভাবে প্রক্রিয়াকরণ করা।
- ইনজেকশনের ঝুঁকি কমাতে আপনার অ্যাপ্লিকেশন কোন স্ক্রিপ্টগুলো চালাতে পারবে তা নিয়ন্ত্রণ করতে কন্টেন্ট সিকিউরিটি পলিসি (CSP) ব্যবহার করুন।
- বিপজ্জনক জাভাস্ক্রিপ্ট এপিআই-তে পাঠানো ডেটার পরিচ্ছন্নতা নিশ্চিত করতে ট্রাস্টেড টাইপস ব্যবহার করুন।
- আপনার ওয়েবসাইটের রিসোর্সগুলোর MIME টাইপকে ব্রাউজার যাতে ভুলভাবে ব্যাখ্যা না করে, তা প্রতিরোধ করতে X-Content-Type-Options ব্যবহার করুন, কারণ এর ফলে স্ক্রিপ্ট এক্সিকিউট হতে পারে।
আপনার সাইটকে অন্যান্য ওয়েবসাইট থেকে আলাদা করুন
ওয়েবের উন্মুক্ততা ওয়েবসাইটগুলোকে একে অপরের সাথে এমনভাবে যোগাযোগ করার সুযোগ দেয়, যা কোনো অ্যাপ্লিকেশনের নিরাপত্তা প্রত্যাশা লঙ্ঘন করতে পারে। এর মধ্যে রয়েছে অপ্রত্যাশিতভাবে প্রমাণীকৃত অনুরোধ পাঠানো অথবা আক্রমণকারীর ডকুমেন্টে অন্য কোনো অ্যাপ্লিকেশন থেকে ডেটা এমবেড করা, যা আক্রমণকারীকে অ্যাপ্লিকেশনের ডেটা পরিবর্তন বা পড়ার সুযোগ করে দেয়।
ওয়েব আইসোলেশনকে দুর্বল করে এমন সাধারণ দুর্বলতাগুলোর মধ্যে রয়েছে ক্লিকজ্যাকিং , ক্রস-সাইট রিকোয়েস্ট ফোরজারি (CSRF), ক্রস-সাইট স্ক্রিপ্ট ইনক্লুশন (XSSI) এবং বিভিন্ন ধরনের ক্রস-সাইট লিক ।
- আপনার ডকুমেন্টগুলোকে কোনো ক্ষতিকারক ওয়েবসাইট দ্বারা এমবেড হওয়া থেকে রক্ষা করতে X-Frame-Options ব্যবহার করুন।
- আপনার ওয়েবসাইটের রিসোর্সসমূহকে কোনো ক্রস-অরিজিন ওয়েবসাইটে অন্তর্ভুক্ত হওয়া থেকে বিরত রাখতে ক্রস-অরিজিন রিসোর্স পলিসি (CORP) ব্যবহার করুন।
- আপনার ওয়েবসাইটের উইন্ডোগুলোকে ক্ষতিকারক ওয়েবসাইটের হস্তক্ষেপ থেকে সুরক্ষিত রাখতে ক্রস-অরিজিন ওপেনার পলিসি (COOP) ব্যবহার করুন।
- ক্রস-অরিজিন ডকুমেন্ট থেকে আপনার ওয়েবসাইটের রিসোর্সগুলিতে অ্যাক্সেস নিয়ন্ত্রণ করতে ক্রস-অরিজিন রিসোর্স শেয়ারিং (CORS) ব্যবহার করুন।
আপনি যদি এই শিরোনামগুলিতে আগ্রহী হন, তবে 'পোস্ট-স্পেকট্র ওয়েব ডেভেলপমেন্ট' বইটি একটি চমৎকার পাঠ্য।
নিরাপদে একটি শক্তিশালী ওয়েবসাইট তৈরি করুন
স্পেক্টার একই ব্রাউজিং কনটেক্সট গ্রুপে লোড করা যেকোনো ডেটাকে সেম-অরিজিন পলিসি থাকা সত্ত্বেও পাঠযোগ্য করে তোলে। ব্রাউজারগুলো " ক্রস-অরিজিন আইসোলেশন " নামক একটি বিশেষ পরিবেশের আড়ালে এমন সব ফিচার সীমাবদ্ধ করে, যা এই দুর্বলতার সুযোগ নিতে পারে। ক্রস-অরিজিন আইসোলেশনের মাধ্যমে আপনি SharedArrayBuffer মতো শক্তিশালী ফিচার ব্যবহার করতে পারেন।
- ক্রস-অরিজিন আইসোলেশন সক্রিয় করতে COOP-এর সাথে ক্রস-অরিজিন এমবেডার পলিসি (COEP) ব্যবহার করুন।
আপনার সাইটের ট্র্যাফিক এনক্রিপ্ট করুন
যখন কোনো অ্যাপ্লিকেশন স্থানান্তরের সময় ডেটা সম্পূর্ণরূপে এনক্রিপ্ট করে না, তখন এনক্রিপশন সমস্যা দেখা দেয়, যার ফলে আড়ি পেতে থাকা আক্রমণকারীরা অ্যাপ্লিকেশনটির সাথে ব্যবহারকারীর কার্যকলাপ সম্পর্কে জানতে পারে।
নিম্নলিখিত ক্ষেত্রে অপর্যাপ্ত এনক্রিপশন দেখা দিতে পারে: HTTPS ব্যবহার না করা, মিশ্র কন্টেন্ট , Secure অ্যাট্রিবিউট (বা __Secure প্রিফিক্স ) ছাড়া কুকি সেট করা, অথবা শিথিল CORS ভ্যালিডেশন লজিক ।
- HTTPS-এর মাধ্যমে আপনার কন্টেন্ট ধারাবাহিকভাবে পরিবেশন করতে HTTP Strict Transport Security (HSTS) ব্যবহার করুন।
বিষয়বস্তু নিরাপত্তা নীতি (সিএসপি)
ক্রস-সাইট স্ক্রিপ্টিং (XSS) হলো এমন এক ধরনের আক্রমণ, যেখানে কোনো ওয়েবসাইটের দুর্বলতার সুযোগ নিয়ে একটি ক্ষতিকারক স্ক্রিপ্ট প্রবেশ করিয়ে তা কার্যকর করা হয়।
Content-Security-Policy পেজ দ্বারা কোন স্ক্রিপ্টগুলো চালানো যাবে তা সীমাবদ্ধ করার মাধ্যমে XSS আক্রমণ প্রতিরোধের জন্য একটি অতিরিক্ত স্তর প্রদান করে।
নিম্নলিখিত পদ্ধতিগুলোর মধ্যে যেকোনো একটি ব্যবহার করে কঠোর CSP সক্রিয় করার পরামর্শ দেওয়া হচ্ছে:
- আপনি যদি সার্ভারে আপনার HTML পেজগুলো রেন্ডার করেন, তাহলে একটি ননস-ভিত্তিক স্ট্রিক্ট CSP ব্যবহার করুন।
- যদি আপনার HTML স্ট্যাটিক্যালি সার্ভ করতে বা ক্যাশ করতে হয়, উদাহরণস্বরূপ যদি এটি একটি সিঙ্গেল-পেজ অ্যাপ্লিকেশন হয়, তাহলে হ্যাশ-ভিত্তিক স্ট্রিক্ট CSP ব্যবহার করুন।
ব্যবহারের উদাহরণ: একটি ননস-ভিত্তিক CSP
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
প্রস্তাবিত ব্যবহার
১. একটি ননস-ভিত্তিক স্ট্রিক্ট সিএসপি ব্যবহার করুন {: #nonce-based-csp}
আপনি যদি সার্ভারে আপনার HTML পেজগুলো রেন্ডার করেন, তাহলে একটি ননস-ভিত্তিক স্ট্রিক্ট CSP ব্যবহার করুন।
সার্ভার সাইডে প্রতিটি অনুরোধের জন্য একটি নতুন স্ক্রিপ্ট ননস ভ্যালু তৈরি করুন এবং নিম্নলিখিত হেডারটি সেট করুন:
সার্ভার কনফিগারেশন ফাইল
Content-Security-Policy: script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'none';
HTML-এ স্ক্রিপ্ট লোড করার জন্য, সমস্ত <script> ট্যাগের nonce অ্যাট্রিবিউটকে একই {RANDOM1} স্ট্রিং-এ সেট করুন।
index.html
<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
// Inline scripts can be used with the <code>nonce</code> attribute.
</script>গুগল ফটোস হলো ননস-ভিত্তিক কঠোর সিএসপি-র একটি ভালো উদাহরণ। এটি কীভাবে ব্যবহৃত হয় তা দেখতে ডেভটুলস ব্যবহার করুন।
২. একটি হ্যাশ-ভিত্তিক স্ট্রিক্ট সিএসপি ব্যবহার করুন {: #hash-based-csp}
যদি আপনার HTML স্ট্যাটিক্যালি সার্ভ করতে বা ক্যাশ করতে হয়, উদাহরণস্বরূপ যদি আপনি একটি সিঙ্গেল-পেজ অ্যাপ্লিকেশন তৈরি করেন, তাহলে হ্যাশ-ভিত্তিক স্ট্রিক্ট CSP ব্যবহার করুন।
সার্ভার কনফিগারেশন ফাইল
Content-Security-Policy: script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'none';
এইচটিএমএল-এ হ্যাশ-ভিত্তিক নীতি প্রয়োগ করার জন্য আপনাকে আপনার স্ক্রিপ্টগুলো ইনলাইন করতে হবে, কারণ বেশিরভাগ ব্রাউজার এক্সটার্নাল স্ক্রিপ্ট হ্যাশ করা সমর্থন করে না ।
index.html
<script> ...// your script1, inlined </script> <script> ...// your script2, inlined </script>
বাহ্যিক স্ক্রিপ্ট লোড করতে, অপশন বি: হ্যাশ-ভিত্তিক সিএসপি রেসপন্স হেডার বিভাগের অধীনে 'ডাইনামিকভাবে সোর্স করা স্ক্রিপ্ট লোড করুন' অংশটি পড়ুন।
CSP Evaluator আপনার CSP মূল্যায়ন করার জন্য একটি ভালো টুল, এবং একই সাথে এটি একটি চমৎকার ননস-ভিত্তিক স্ট্রিক্ট CSP উদাহরণ। এটি কীভাবে ব্যবহার করা হয় তা দেখতে DevTools ব্যবহার করুন।
সমর্থিত ব্রাউজার
CSP সম্পর্কে আরও কিছু বিষয় লক্ষণীয়।
-
frame-ancestorsডিরেক্টিভ আপনার সাইটকে ক্লিকজ্যাকিং থেকে রক্ষা করে—এই ঝুঁকিটি তৈরি হয় যখন আপনি অবিশ্বস্ত সাইটগুলোকে আপনার সাইট এমবেড করার অনুমতি দেন। আপনি যদি আরও সহজ সমাধান চান, তবে লোড হওয়া ব্লক করতেX-Frame-Optionsব্যবহার করতে পারেন, কিন্তুframe-ancestorsআপনাকে একটি উন্নত কনফিগারেশনের সুবিধা দেয়, যার মাধ্যমে আপনি শুধুমাত্র নির্দিষ্ট অরিজিনগুলোকে এমবেডার হিসেবে অনুমতি দিতে পারেন। - আপনার সাইটের সমস্ত রিসোর্স যেন HTTPS-এর মাধ্যমে লোড হয়, তা নিশ্চিত করতে আপনি হয়তো একটি CSP ব্যবহার করে থাকতে পারেন। এর প্রাসঙ্গিকতা এখন কমে গেছে, কারণ আজকাল বেশিরভাগ ব্রাউজারই মিক্সড-কন্টেন্ট ব্লক করে দেয়।
- আপনি রিপোর্ট-অনলি মোডেও একটি CSP সেট করতে পারেন।
- যদি আপনি সার্ভার-সাইডে কোনো CSP হেডার হিসেবে সেট করতে না পারেন, তবে আপনি এটিকে মেটা ট্যাগ হিসেবেও সেট করতে পারেন। মনে রাখবেন যে, আপনি মেটা ট্যাগের জন্য রিপোর্ট-অনলি মোড ব্যবহার করতে পারবেন না (যদিও এটি ভবিষ্যতে পরিবর্তিত হতে পারে )।
আরও জানুন
বিশ্বস্ত প্রকার
DOM-ভিত্তিক XSS হলো এমন এক ধরনের আক্রমণ, যেখানে ক্ষতিকারক ডেটা এমন কোনো সিঙ্কে পাঠানো হয় যা ডাইনামিক কোড এক্সিকিউশন সমর্থন করে, যেমন eval() বা .innerHTML ।
ট্রাস্টেড টাইপস DOM XSS-মুক্ত অ্যাপ্লিকেশন লেখা, নিরাপত্তা পর্যালোচনা এবং রক্ষণাবেক্ষণের জন্য প্রয়োজনীয় টুল সরবরাহ করে। এগুলি CSP- এর মাধ্যমে সক্রিয় করা যায় এবং বিপজ্জনক ওয়েব API-গুলিকে শুধুমাত্র একটি বিশেষ অবজেক্ট—একটি ট্রাস্টেড টাইপ—গ্রহণে সীমাবদ্ধ করে জাভাস্ক্রিপ্ট কোডকে ডিফল্টরূপে সুরক্ষিত করে তোলে।
এই অবজেক্টগুলো তৈরি করার জন্য আপনি নিরাপত্তা নীতি নির্ধারণ করতে পারেন, যার মাধ্যমে আপনি নিশ্চিত করতে পারেন যে ডেটা DOM-এ লেখার আগে নিরাপত্তা নিয়মগুলো (যেমন এস্কেপিং বা স্যানিটাইজেশন) ধারাবাহিকভাবে প্রয়োগ করা হয়। এর ফলে কোডের মধ্যে এই নীতিগুলোই একমাত্র স্থান হয়ে দাঁড়ায়, যেখানে সম্ভাব্যভাবে DOM XSS প্রবেশ করাতে পারে।
উদাহরণ ব্যবহার
Content-Security-Policy: require-trusted-types-for 'script'
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\</g, '<').replace(/>/g, '>');
}
});
}
// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.
// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src=x onerror=alert(1)>');
el.innerHTML = escaped; // '&lt;img src=x onerror=alert(1)&gt;'
প্রস্তাবিত ব্যবহার
বিপজ্জনক DOM সিঙ্কগুলির জন্য বিশ্বস্ত প্রকার (Trusted Types) প্রয়োগ করুন CSP এবং বিশ্বস্ত প্রকার হেডার:
Content-Security-Policy: require-trusted-types-for 'script'বর্তমানে
require-trusted-types-forডিরেক্টিভের জন্য'script'হলো একমাত্র গ্রহণযোগ্য মান।অবশ্যই, আপনি ট্রাস্টেড টাইপসকে অন্যান্য সিএসপি নির্দেশাবলীর সাথে একত্রিত করতে পারেন:
উপর থেকে একটি ননস-ভিত্তিক CSP-কে ট্রাস্টেড টাইপস-এর সাথে একীভূত করা:
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
<aside class="note"><b>দ্রষ্টব্য:</b> আপনি একটি অতিরিক্ত <code>trusted-types</code> ডিরেক্টিভ (উদাহরণস্বরূপ, <code>trusted-types myPolicy</code>) সেট করার মাধ্যমে অনুমোদিত Trusted Types পলিসির নাম সীমিত করতে পারেন। তবে, এটি বাধ্যতামূলক নয়।</aside>
একটি নীতি নির্ধারণ করুন
নীতি:
// Feature detection if (window.trustedTypes && trustedTypes.createPolicy) { // Name and create a policy const policy = trustedTypes.createPolicy('escapePolicy', { createHTML: str => { return str.replace(/\/g, '>'); } }); }
নীতিমালা প্রয়োগ করুন
DOM-এ ডেটা লেখার সময় নীতিটি ব্যবহার করুন:
// Assignment of raw strings are blocked by Trusted Types. el.innerHTML = 'some string'; // This throws an exception.</p> <p>// Assignment of Trusted Types is accepted safely. const escaped = policy.createHTML('<img src="x" onerror="alert(1)">'); el.innerHTML = escaped; // '<img src=x onerror=alert(1)>'
require-trusted-types-for 'script'এর সাথে, একটি বিশ্বস্ত টাইপ ব্যবহার করা আবশ্যক। স্ট্রিং-এর সাথে কোনো বিপজ্জনক DOM API ব্যবহার করলে একটি ত্রুটি দেখা দেবে।
সমর্থিত ব্রাউজার
আরও জানুন
- ট্রাস্টেড টাইপস ব্যবহার করে DOM-ভিত্তিক ক্রস-সাইট স্ক্রিপ্টিং দুর্বলতা প্রতিরোধ করুন।
- CSP: HTTP-এর জন্য বিশ্বস্ত প্রকারের প্রয়োজন | MDN
- CSP: বিশ্বস্ত-প্রকার - HTTP | MDN
- ট্রাস্টেড টাইপস ডেমো — ডেভটুলস ইন্সপেক্টর খুলুন এবং দেখুন কী ঘটছে।
X-কন্টেন্ট-টাইপ-অপশন
যখন আপনার ডোমেইন থেকে কোনো ক্ষতিকারক HTML ডকুমেন্ট পরিবেশন করা হয় (উদাহরণস্বরূপ, যদি কোনো ফটো সার্ভিসে আপলোড করা ছবিতে বৈধ HTML মার্কআপ থাকে), তখন কিছু ব্রাউজার সেটিকে একটি সক্রিয় ডকুমেন্ট হিসেবে গণ্য করে এবং অ্যাপ্লিকেশনটির প্রেক্ষাপটে স্ক্রিপ্ট চালানোর অনুমতি দেয়, যার ফলে একটি ক্রস-সাইট স্ক্রিপ্টিং বাগ দেখা দেয়।
X-Content-Type-Options: nosniff ব্রাউজারকে এই নির্দেশ দিয়ে এটিকে প্রতিরোধ করে যে, একটি নির্দিষ্ট রেসপন্সের জন্য Content-Type হেডারে সেট করা MIME টাইপটি সঠিক। আপনার সমস্ত রিসোর্সের জন্য এই হেডারটি ব্যবহার করার পরামর্শ দেওয়া হয়।
উদাহরণ ব্যবহার
X-Content-Type-Options: nosniff
প্রস্তাবিত ব্যবহার
আপনার সার্ভার থেকে পরিবেশিত সকল রিসোর্সের জন্য সঠিক Content-Type হেডারের সাথে X-Content-Type-Options: nosniff ব্যবহার করার পরামর্শ দেওয়া হয়।

একটি HTML ডকুমেন্টের সাথে পাঠানো হেডারগুলির উদাহরণ
X-Content-Type-Options: nosniff Content-Type: text/html; charset=utf-8
সমর্থিত ব্রাউজার
আরও জানুন
এক্স-ফ্রেম-বিকল্প
যদি কোনো ক্ষতিকারক ওয়েবসাইট আপনার সাইটকে আইফ্রেম হিসেবে এমবেড করতে পারে, তবে আক্রমণকারীরা ক্লিকজ্যাকিংয়ের মাধ্যমে ব্যবহারকারীর দ্বারা অনাকাঙ্ক্ষিত কার্যকলাপ সংঘটিত করতে পারে। এছাড়াও, কিছু ক্ষেত্রে স্পেক্টার-ধরনের আক্রমণ ক্ষতিকারক ওয়েবসাইটগুলোকে এমবেড করা ডকুমেন্টের বিষয়বস্তু সম্পর্কে জানার সুযোগ করে দেয়।
X-Frame-Options নির্দেশ করে যে একটি ব্রাউজারকে <frame> , <iframe> , <embed> , বা <object> এর মধ্যে একটি পৃষ্ঠা রেন্ডার করার অনুমতি দেওয়া হবে কি না। সমস্ত ডকুমেন্টকে এই হেডারটি পাঠানোর পরামর্শ দেওয়া হয়, যা নির্দেশ করে যে তারা অন্য ডকুমেন্ট দ্বারা এমবেড হওয়ার অনুমতি দেয় কি না।
উদাহরণ ব্যবহার
X-Frame-Options: DENY
প্রস্তাবিত ব্যবহার
যেসব ডকুমেন্ট এমবেড করার জন্য ডিজাইন করা হয়নি, সেগুলোতে X-Frame-Options হেডার ব্যবহার করা উচিত।
এই ডেমোতে একটি আইফ্রেম লোড করার ক্ষেত্রে নিম্নলিখিত কনফিগারেশনগুলো কীভাবে প্রভাব ফেলে, তা আপনি পরীক্ষা করে দেখতে পারেন। X-Frame-Options ড্রপডাউন মেনুটি পরিবর্তন করুন এবং ' Reload the iframe' বোতামে ক্লিক করুন।
আপনার ওয়েবসাইটকে অন্য কোনো ওয়েবসাইট দ্বারা এমবেড হওয়া থেকে সুরক্ষিত রাখে।
অন্য কোনো নথিতে অন্তর্ভুক্ত থাকার বিষয়টি অস্বীকার করুন।

X-Frame-Options: DENYআপনার ওয়েবসাইটকে যেকোনো ক্রস-অরিজিন ওয়েবসাইট দ্বারা এমবেড হওয়া থেকে সুরক্ষিত রাখে।
শুধুমাত্র একই-অরিজিন ডকুমেন্ট দ্বারা এমবেড করার অনুমতি দিন।
X-Frame-Options: SAMEORIGINসমর্থিত ব্রাউজার
আরও জানুন
ক্রস-অরিজিন রিসোর্স পলিসি (CORP)
একজন আক্রমণকারী ওয়েব-ভিত্তিক ক্রস-সাইট লিক কাজে লাগিয়ে অন্য কোনো উৎস, যেমন আপনার সাইট থেকে, রিসোর্স এমবেড করে তাদের সম্পর্কে তথ্য জানতে পারে।
Cross-Origin-Resource-Policy কোন কোন ওয়েবসাইট দ্বারা এটি লোড হতে পারে তা নির্দেশ করার মাধ্যমে এই ঝুঁকি প্রশমিত করে। হেডারটি তিনটি মানের মধ্যে যেকোনো একটি গ্রহণ করে: same-origin , same-site , এবং cross-origin । সকল রিসোর্সকে এই হেডারটি পাঠানোর পরামর্শ দেওয়া হয়, যাতে এটি নির্দেশ করে যে তারা অন্য ওয়েবসাইট দ্বারা লোড হওয়ার অনুমতি দেয় কিনা।
উদাহরণ ব্যবহার
Cross-Origin-Resource-Policy: same-origin
প্রস্তাবিত ব্যবহার
সকল রিসোর্স নিম্নলিখিত তিনটি হেডারের যেকোনো একটির সাথে পরিবেশন করার পরামর্শ দেওয়া হয়।
এই ডেমোতে ` Cross-Origin-Embedder-Policy: require-corp এনভায়রনমেন্টের অধীনে রিসোর্স লোড করার ক্ষেত্রে নিম্নলিখিত কনফিগারেশনগুলো কীভাবে প্রভাব ফেলে, তা আপনি পরীক্ষা করে দেখতে পারেন। এর প্রভাব দেখার জন্য ` Cross-Origin-Resource-Policy` ড্রপডাউন মেনুটি পরিবর্তন করুন এবং ` Reload the iframe` অথবা `Reload the image` বোতামে ক্লিক করুন।
cross-origin রিসোর্স লোড করার অনুমতি দিন
সিডিএন-সদৃশ পরিষেবাগুলিকে রিসোর্সগুলিতে cross-origin প্রয়োগ করার পরামর্শ দেওয়া হয় (যেহেতু সেগুলি সাধারণত ক্রস-অরিজিন পেজ দ্বারা লোড হয়), যদি না সেগুলি ইতিমধ্যেই CORS-এর মাধ্যমে পরিবেশিত হয়ে থাকে, যার একটি অনুরূপ প্রভাব রয়েছে।

Cross-Origin-Resource-Policy: cross-origin same-origin থেকে লোড করা রিসোর্স সীমিত করুন
যেসব রিসোর্স শুধুমাত্র সেম-অরিজিন পেজ দ্বারা লোড করার জন্য তৈরি, সেগুলোতে same-origin প্রয়োগ করা উচিত। যেসব রিসোর্সে ব্যবহারকারীর সংবেদনশীল তথ্য থাকে, অথবা এমন কোনো এপিআই-এর রেসপন্সের ক্ষেত্রে এটি প্রয়োগ করা উচিত যা শুধুমাত্র সেম-অরিজিন থেকে কল করার জন্য তৈরি।
মনে রাখবেন যে, এই হেডারযুক্ত রিসোর্সগুলি সরাসরি লোড করা যেতে পারে, উদাহরণস্বরূপ একটি নতুন ব্রাউজার উইন্ডোতে URL-টিতে গিয়ে। ক্রস-অরিজিন রিসোর্স পলিসি শুধুমাত্র রিসোর্সটিকে অন্য ওয়েবসাইট দ্বারা এমবেড হওয়া থেকে রক্ষা করে।

Cross-Origin-Resource-Policy: same-origin same-site থেকে রিসোর্স লোড করা সীমিত করুন।
উপরেরটির মতো রিসোর্সগুলোর ক্ষেত্রে same-site প্রয়োগ করার পরামর্শ দেওয়া হয়, যেগুলো আপনার সাইটের অন্যান্য সাবডোমেন দ্বারা লোড করার জন্য তৈরি।

Cross-Origin-Resource-Policy: same-siteসমর্থিত ব্রাউজার
আরও জানুন
ক্রস-অরিজিন ওপেনার পলিসি (COOP)
একজন আক্রমণকারীর ওয়েবসাইট ওয়েব-ভিত্তিক ক্রস-সাইট লিক কাজে লাগিয়ে একটি পপ-আপ উইন্ডোতে অন্য একটি সাইট খুলে সেটির তথ্য জানতে পারে। কিছু ক্ষেত্রে, এটি স্পেক্টার (Spectre) ভিত্তিক সাইড-চ্যানেল অ্যাটাক চালানোর সুযোগও করে দিতে পারে।
Cross-Origin-Opener-Policy হেডারটি একটি ডকুমেন্টকে window.open() অথবা rel="noopener" ছাড়া target="_blank" যুক্ত কোনো লিঙ্কের মাধ্যমে খোলা ক্রস-অরিজিন উইন্ডোগুলো থেকে নিজেকে বিচ্ছিন্ন রাখার একটি উপায় প্রদান করে। এর ফলে, ডকুমেন্টটির যেকোনো ক্রস-অরিজিন ওপেনারের কাছে এটির কোনো রেফারেন্স থাকবে না এবং এটির সাথে ইন্টারঅ্যাক্ট করতে পারবে না।
উদাহরণ ব্যবহার
Cross-Origin-Opener-Policy: same-origin-allow-popups
প্রস্তাবিত ব্যবহার
এই ডেমোতে আপনি পরীক্ষা করে দেখতে পারেন যে নিম্নলিখিত কনফিগারেশনগুলি একটি ক্রস-অরিজিন পপআপ উইন্ডোর সাথে যোগাযোগকে কীভাবে প্রভাবিত করে। ডকুমেন্ট এবং পপআপ উইন্ডো উভয়ের জন্য Cross-Origin-Opener-Policy ড্রপডাউন মেনুটি পরিবর্তন করুন, Open a popup বোতামে ক্লিক করুন এবং তারপরে বার্তাটি আসলেই ডেলিভার হয়েছে কিনা তা দেখতে Send a postMessage-এ ক্লিক করুন।
ক্রস-অরিজিন উইন্ডো থেকে একটি ডকুমেন্টকে আলাদা করুন
same-origin সেট করলে ডকুমেন্টটি ক্রস-অরিজিন ডকুমেন্ট উইন্ডোগুলো থেকে বিচ্ছিন্ন হয়ে যায়।

Cross-Origin-Opener-Policy: same-originক্রস-অরিজিন উইন্ডোগুলো থেকে একটি ডকুমেন্টকে আলাদা করুন কিন্তু পপআপের অনুমতি দিন।
same-origin-allow-popups সেট করলে একটি ডকুমেন্ট তার পপআপ উইন্ডোগুলোর একটি রেফারেন্স ধরে রাখতে পারে, যদি না তারা COOP-তে same-origin বা same-origin-allow-popups সেট করে। এর মানে হলো, same-origin-allow-popups ডকুমেন্টটিকে পপআপ উইন্ডো হিসেবে খোলার সময় রেফারেন্স হওয়া থেকে রক্ষা করতে পারে, কিন্তু এটিকে তার নিজের পপআপগুলোর সাথে যোগাযোগ করার অনুমতি দেয়।

Cross-Origin-Opener-Policy: same-origin-allow-popupsক্রস-অরিজিন উইন্ডো দ্বারা একটি ডকুমেন্টকে রেফারেন্স করার অনুমতি দিন
unsafe-none হলো ডিফল্ট মান, কিন্তু আপনি স্পষ্টভাবে নির্দেশ করতে পারেন যে এই ডকুমেন্টটি একটি ক্রস-অরিজিন উইন্ডো দ্বারা খোলা যাবে এবং পারস্পরিক অ্যাক্সেস বজায় থাকবে।

Cross-Origin-Opener-Policy: unsafe-noneCOOP-এর সাথে বেমানান রিপোর্ট প্যাটার্ন
যখন COOP রিপোর্টিং এপিআই-এর সাথে ক্রস-উইন্ডো ইন্টারঅ্যাকশন প্রতিরোধ করে, তখন আপনি রিপোর্ট পেতে পারেন।
Cross-Origin-Opener-Policy: same-origin; report-to="coop"COOP একটি রিপোর্ট-অনলি মোডও সমর্থন করে, যার ফলে আপনি বিভিন্ন অরিজিনের ডকুমেন্টের মধ্যে যোগাযোগে বাধা না দিয়েই রিপোর্ট গ্রহণ করতে পারেন।
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"সমর্থিত ব্রাউজার
আরও জানুন
ক্রস-অরিজিন রিসোর্স শেয়ারিং (CORS)
এই নিবন্ধের অন্যান্য বিষয়ের মতো, ক্রস-অরিজিন রিসোর্স শেয়ারিং (CORS) কোনো হেডার নয়, বরং এটি একটি ব্রাউজার ব্যবস্থা যা বিভিন্ন অরিজিনের রিসোর্সের জন্য অনুরোধ করে এবং সেগুলোতে অ্যাক্সেসের অনুমতি দেয়।
ডিফল্টরূপে, ব্রাউজারগুলো একটি ওয়েব পেজকে ক্রস-অরিজিন রিসোর্স অ্যাক্সেস করা থেকে বিরত রাখতে সেম-অরিজিন পলিসি (SEM) প্রয়োগ করে। উদাহরণস্বরূপ, যখন একটি ক্রস-অরিজিন ছবি লোড করা হয়, তখন ওয়েব পেজে দৃশ্যত প্রদর্শিত হলেও, পেজের জাভাস্ক্রিপ্ট ছবিটির ডেটা অ্যাক্সেস করতে পারে না। রিসোর্স প্রোভাইডার CORS-এর মাধ্যমে অপ্ট-ইন করে এই বিধিনিষেধ শিথিল করতে পারে এবং অন্যান্য ওয়েবসাইটকে রিসোর্সটি পড়ার অনুমতি দিতে পারে।
উদাহরণ ব্যবহার
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
CORS কীভাবে কনফিগার করতে হয় তা জানার আগে, রিকোয়েস্ট টাইপগুলোর মধ্যে পার্থক্য বোঝা সহায়ক। রিকোয়েস্টের বিবরণের উপর নির্ভর করে, একটি রিকোয়েস্টকে সিম্পল রিকোয়েস্ট বা প্রিফ্লাইটেড রিকোয়েস্ট হিসাবে শ্রেণীবদ্ধ করা হবে।
একটি সাধারণ অনুরোধের মানদণ্ড:
- মেথডটি হলো
GET,HEADবাPOST। - কাস্টম হেডারগুলোতে শুধুমাত্র
Accept,Accept-Language,Content-LanguageএবংContent-Typeঅন্তর্ভুক্ত থাকে। -
Content-Typeহলোapplication/x-www-form-urlencoded,multipart/form-data, অথবাtext/plain।
বাকি সবকিছুকে প্রিফ্লাইটেড রিকোয়েস্ট হিসেবে শ্রেণীবদ্ধ করা হয়। আরও বিস্তারিত জানতে, Cross-Origin Resource Sharing (CORS) - HTTP | MDN দেখুন।
প্রস্তাবিত ব্যবহার
সহজ অনুরোধ
যখন কোনো অনুরোধ সাধারণ অনুরোধের শর্ত পূরণ করে, তখন ব্রাউজার একটি Origin হেডার সহ একটি ক্রস-অরিজিন অনুরোধ পাঠায়, যা অনুরোধকারী অরিজিনকে নির্দেশ করে।
অনুরোধ হেডারের উদাহরণ
Get / HTTP/1.1 Origin: https://example.com
উদাহরণ প্রতিক্রিয়া হেডার
Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://example.comনির্দেশ করে যেhttps://example.comরেসপন্সের বিষয়বস্তু অ্যাক্সেস করতে পারবে। যে রিসোর্সগুলো যেকোনো সাইট দ্বারা পাঠযোগ্য হওয়ার জন্য তৈরি, সেগুলো এই হেডারটিকে*এ সেট করতে পারে, সেক্ষেত্রে ব্রাউজার ক্রেডেনশিয়াল ছাড়াই শুধুমাত্র অনুরোধটি করার জন্য বলবে।-
Access-Control-Allow-Credentials: trueনির্দেশ করে যে, ক্রেডেনশিয়াল (কুকি) বহনকারী অনুরোধগুলোকে রিসোর্সটি লোড করার অনুমতি দেওয়া হয়। অন্যথায়, অনুরোধকারী অরিজিনAccess-Control-Allow-Originহেডারে উপস্থিত থাকলেও প্রমাণীকৃত অনুরোধগুলো প্রত্যাখ্যান করা হবে।
এই ডেমোতে আপনি দেখতে পারেন কিভাবে একটি Cross-Origin-Embedder-Policy: require-corp পরিবেশে একটি সাধারণ অনুরোধ রিসোর্স লোড করাকে প্রভাবিত করে। এর প্রভাব দেখতে Cross-Origin Resource Sharing চেকবক্সে ক্লিক করুন এবং Reload the image বোতামে ক্লিক করুন।
প্রাক-উড্ডয়ন অনুরোধ
একটি প্রিফ্লাইটেড রিকোয়েস্টের আগে একটি OPTIONS রিকোয়েস্ট পাঠানো হয়, যা যাচাই করে যে পরবর্তী রিকোয়েস্টটি পাঠানোর অনুমতি আছে কিনা।
অনুরোধ হেডারের উদাহরণ
OPTIONS / HTTP/1.1 Origin: https://example.com Access-Control-Request-Method: POST Access-Control-Request-Headers: X-PINGOTHER, Content-Type
Access-Control-Request-Method: POSTPOSTব্যবহার করে নিম্নলিখিত অনুরোধগুলো করা যায়।-
Access-Control-Request-Headers: X-PINGOTHER, Content-Typeবিকল্পটি অনুরোধকারীকে পরবর্তী অনুরোধেX-PINGOTHERএবংContent-TypeHTTP হেডার সেট করার অনুমতি দেয়।
উদাহরণস্বরূপ প্রতিক্রিয়া হেডার
Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true Access-Control-Allow-Methods: POST, GET, OPTIONS Access-Control-Allow-Headers: X-PINGOTHER, Content-Type Access-Control-Max-Age: 86400
Access-Control-Allow-Methods: POST, GET, OPTIONSনির্দেশ করে যে পরবর্তী অনুরোধগুলিPOST,GETএবংOPTIONSপদ্ধতি ব্যবহার করে করা যেতে পারে।-
Access-Control-Allow-Headers: X-PINGOTHER, Content-Typeনির্দেশ করে যে পরবর্তী অনুরোধগুলিতেX-PINGOTHERএবংContent-Typeহেডার অন্তর্ভুক্ত করা যেতে পারে। -
Access-Control-Max-Age: 86400নির্দেশ করে যে প্রিফ্লাইটেড অনুরোধের ফলাফল ৮৬৪০০ সেকেন্ডের জন্য ক্যাশ করে রাখা যাবে।
সমর্থিত ব্রাউজার
আরও জানুন
ক্রস-অরিজিন এমবেডার পলিসি (COEP)
স্পেক্টার-ভিত্তিক আক্রমণের মাধ্যমে ক্রস-অরিজিন রিসোর্স চুরির ক্ষমতা কমাতে, SharedArrayBuffer বা performance.measureUserAgentSpecificMemory() এর মতো ফিচারগুলো ডিফল্টরূপে নিষ্ক্রিয় থাকে।
Cross-Origin-Embedder-Policy: require-corp ডকুমেন্ট এবং ওয়ার্কারদেরকে ক্রস-অরিজিন রিসোর্স, যেমন ছবি, স্ক্রিপ্ট, স্টাইলশিট, আইফ্রেম এবং অন্যান্য লোড করা থেকে বিরত রাখে, যদি না এই রিসোর্সগুলি CORS বা CORP হেডারের মাধ্যমে স্পষ্টভাবে লোড হওয়ার জন্য সম্মতি দেয়। কোনো ডকুমেন্টকে ক্রস-অরিজিন আইসোলেশনে অন্তর্ভুক্ত করার জন্য COEP-কে Cross-Origin-Opener-Policy সাথে একত্রিত করা যেতে পারে।
আপনার ডকুমেন্টের জন্য ক্রস-অরিজিন আইসোলেশন সক্রিয় করতে চাইলে Cross-Origin-Embedder-Policy: require-corp ব্যবহার করুন।
উদাহরণ ব্যবহার
Cross-Origin-Embedder-Policy: require-corp
উদাহরণ ব্যবহার
COEP-এর একটিমাত্র ভ্যালু হলো require-corp । এই হেডারটি পাঠানোর মাধ্যমে, আপনি ব্রাউজারকে সেইসব রিসোর্স লোড করা ব্লক করার নির্দেশ দিতে পারেন, যেগুলো CORS বা CORP-এর মাধ্যমে অপ্ট-ইন করেনি।

এই ডেমোতে নিম্নলিখিত কনফিগারেশনগুলো রিসোর্স লোড করার উপর কীভাবে প্রভাব ফেলে তা আপনি পরীক্ষা করে দেখতে পারেন। রিসোর্স লোড করার উপর এগুলোর প্রভাব দেখতে Cross-Origin-Embedder-Policy ড্রপডাউন মেনু, Cross-Origin-Resource-Policy ড্রপডাউন মেনু, Report Only চেকবক্স ইত্যাদি পরিবর্তন করুন। এছাড়াও, ব্লক করা রিসোর্সগুলো রিপোর্ট করা হচ্ছে কিনা তা দেখতে রিপোর্টিং এন্ডপয়েন্ট ডেমোটি খুলুন।
ক্রস-অরিজিন আইসোলেশন সক্ষম করুন
Cross-Origin-Embedder-Policy: require-corp এর সাথে Cross-Origin-Opener-Policy: same-origin পাঠিয়ে ক্রস-অরিজিন আইসোলেশন সক্রিয় করুন।
Cross-Origin-Embedder-Policy: require-corp Cross-Origin-Opener-Policy: same-origin
COEP-এর সাথে অসামঞ্জস্যপূর্ণ রিসোর্স রিপোর্ট করুন।
আপনি রিপোর্টিং এপিআই (Reporting API) ব্যবহার করে COEP-এর কারণে অবরুদ্ধ রিসোর্সগুলির রিপোর্ট পেতে পারেন।
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"COEP শুধুমাত্র-প্রতিবেদন মোডও সমর্থন করে, যার ফলে আপনি লোডিং রিসোর্স ব্লক না করেই রিপোর্ট গ্রহণ করতে পারেন।
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"সমর্থিত ব্রাউজার
আরও জানুন
HTTP কঠোর পরিবহন নিরাপত্তা (HSTS)
সাধারণ HTTP সংযোগের মাধ্যমে যোগাযোগ এনক্রিপ্ট করা হয় না, ফলে স্থানান্তরিত ডেটা নেটওয়ার্ক-স্তরের আড়িপাতাকারীদের কাছে সহজলভ্য হয়ে যায়।
Strict-Transport-Security হেডার ব্রাউজারকে জানিয়ে দেয় যে, সাইটটি যেন কখনোই HTTP ব্যবহার করে লোড না করা হয় এবং এর পরিবর্তে HTTPS ব্যবহার করা হয়। এটি সেট করা হয়ে গেলে, ব্রাউজারটি হেডারে নির্ধারিত সময়কাল পর্যন্ত কোনো রিডাইরেক্ট ছাড়াই ডোমেইনটি অ্যাক্সেস করার জন্য HTTP-এর পরিবর্তে HTTPS ব্যবহার করবে।
উদাহরণ ব্যবহার
Strict-Transport-Security: max-age=31536000
প্রস্তাবিত ব্যবহার
যেসব ওয়েবসাইট HTTP থেকে HTTPS-এ রূপান্তরিত হচ্ছে, তাদের HTTP সহ কোনো অনুরোধ পেলে Strict-Transport-Security হেডার দিয়ে সাড়া দেওয়া উচিত।
Strict-Transport-Security: max-age=31536000