রেফারার এবং রেফারার-নীতির সর্বোত্তম অনুশীলন

Maud Nalpas

এই পৃষ্ঠায় আপনার রেফারার-পলিসি সেট করার এবং আগত অনুরোধগুলিতে রেফারার ব্যবহার করার কিছু সর্বোত্তম পদ্ধতি তুলে ধরা হয়েছে।

সারসংক্ষেপ

• অপ্রত্যাশিত আন্তঃউৎস তথ্য ফাঁস ওয়েব ব্যবহারকারীদের গোপনীয়তার ক্ষতি করে। একটি সুরক্ষামূলক রেফারার নীতি এক্ষেত্রে সাহায্য করতে পারে।
• strict-origin-when-cross-origin ’ রেফারার পলিসি সেট করার কথা বিবেচনা করুন। এটি রেফারারের বেশিরভাগ উপযোগিতা বজায় রাখে এবং একই সাথে বিভিন্ন অরিজিনের মধ্যে ডেটা ফাঁসের ঝুঁকি হ্রাস করে।
• ক্রস-সাইট রিকোয়েস্ট ফরজেরি (CSRF) সুরক্ষার জন্য রেফারার ব্যবহার করবেন না। এর পরিবর্তে CSRF টোকেন এবং অতিরিক্ত নিরাপত্তা স্তর হিসেবে অন্যান্য হেডার ব্যবহার করুন।

রেফারার এবং রেফারার-নীতি 101

HTTP অনুরোধে একটি ঐচ্ছিক Referer হেডার অন্তর্ভুক্ত থাকতে পারে, যা নির্দেশ করে যে অনুরোধটি কোন উৎস বা ওয়েব পেজের URL থেকে করা হয়েছে। Referrer-Policy হেডারটি নির্ধারণ করে যে Referer হেডারে কোন ডেটা উপলব্ধ করা হবে।

নিম্নলিখিত উদাহরণে, Referer হেডারে site-one এর সেই পেজটির সম্পূর্ণ URL অন্তর্ভুক্ত করা হয়েছে যেখান থেকে অনুরোধটি করা হয়েছিল।

Referer হেডারটি বিভিন্ন ধরনের অনুরোধে উপস্থিত থাকতে পারে:

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

ন্যাভিগেশন এবং আইফ্রেমের ক্ষেত্রে, আপনি জাভাস্ক্রিপ্ট ব্যবহার করে document.referrer মাধ্যমেও এই ডেটা অ্যাক্সেস করতে পারেন।

Referer ভ্যালু থেকে আপনি অনেক কিছু জানতে পারেন। উদাহরণস্বরূপ, একটি অ্যানালিটিক্স সার্ভিস এটি ব্যবহার করে নির্ধারণ করতে পারে যে site-two.example এর ৫০% ভিজিটর social-network.example থেকে এসেছে। কিন্তু যখন পাথ এবং কোয়েরি স্ট্রিং সহ সম্পূর্ণ ইউআরএলটি Referer মাধ্যমে বিভিন্ন অরিজিনে পাঠানো হয়, তখন এটি ব্যবহারকারীর গোপনীয়তাকে বিপন্ন করতে পারে এবং নিরাপত্তা ঝুঁকি তৈরি করতে পারে।

ইউআরএল #১ থেকে #৫-এ ব্যক্তিগত তথ্য এবং কখনও কখনও সংবেদনশীল বা শনাক্তকারী তথ্য থাকে। বিভিন্ন অরিজিন জুড়ে নীরবে এগুলো ফাঁস হয়ে গেলে ওয়েব ব্যবহারকারীদের গোপনীয়তা বিঘ্নিত হতে পারে।

ইউআরএল #৬ একটি ক্যাপাবিলিটি ইউআরএল । উদ্দিষ্ট ব্যবহারকারী ব্যতীত অন্য কেউ এটি পেলে, কোনো ক্ষতিকারক ব্যক্তি সেই ব্যবহারকারীর অ্যাকাউন্টের নিয়ন্ত্রণ নিতে পারে।

আপনার সাইট থেকে করা অনুরোধের জন্য কোন রেফারার ডেটা উপলব্ধ করা হবে তা সীমাবদ্ধ করতে, আপনি একটি রেফারার নীতি নির্ধারণ করতে পারেন।

কী কী পলিসি পাওয়া যায় এবং সেগুলোর মধ্যে পার্থক্য কী?

আপনি আটটি পলিসির মধ্যে যেকোনো একটি বেছে নিতে পারেন। পলিসির ওপর নির্ভর করে, Referer হেডার (এবং document.referrer ) থেকে প্রাপ্ত ডেটাগুলো হতে পারে:

• কোন ডেটা নেই (কোন Referer হেডার উপস্থিত নেই)
• শুধুমাত্র উৎস
• সম্পূর্ণ URL: অরিজিন, পাথ এবং কোয়েরি স্ট্রিং

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

নিম্নলিখিত সারণীটি দেখায় কিভাবে রেফারার পলিসিগুলি রেফারার হেডার এবং document.referrer থেকে প্রাপ্ত URL ডেটাকে সীমাবদ্ধ করে:

MDN নীতিমালা এবং আচরণের উদাহরণগুলোর একটি পূর্ণাঙ্গ তালিকা প্রদান করে।

রেফারার পলিসি নির্ধারণ করার সময় নিম্নলিখিত বিষয়গুলো মনে রাখতে হবে:

• যে সমস্ত পলিসি স্কিমটিকে (HTTPS বনাম HTTP) বিবেচনা করে ( strict-origin , no-referrer-when-downgrade , এবং strict-origin-when-cross-origin ), সেগুলি একটি HTTP অরিজিন থেকে অন্য HTTP অরিজিনে করা অনুরোধকে একটি HTTPS অরিজিন থেকে অন্য HTTPS অরিজিনে করা অনুরোধের মতোই বিবেচনা করে, যদিও HTTP কম সুরক্ষিত। এর কারণ হলো, এই পলিসিগুলোর জন্য যা গুরুত্বপূর্ণ তা হলো সুরক্ষার অবনতি ঘটছে কিনা; অর্থাৎ, অনুরোধটি একটি এনক্রিপ্টেড অরিজিন থেকে একটি আনএনক্রিপ্টেড অরিজিনে ডেটা প্রকাশ করতে পারে কিনা, যেমনটি HTTPS → HTTP অনুরোধের ক্ষেত্রে ঘটে। একটি HTTP → HTTP অনুরোধ সম্পূর্ণরূপে আনএনক্রিপ্টেড, তাই এখানে সুরক্ষার কোনো অবনতি ঘটে না।
• যদি কোনো অনুরোধ সেম-অরিজিন হয়, এর মানে হলো স্কিমটি (HTTPS বা HTTP) একই, তাই এতে নিরাপত্তার কোনো অবনতি হয় না।

ব্রাউজারে ডিফল্ট রেফারার নীতি

অক্টোবর ২০২১ অনুযায়ী

যদি কোনো রেফারার পলিসি সেট করা না থাকে, তাহলে ব্রাউজার তার ডিফল্ট পলিসি ব্যবহার করে।

রেফারার নীতি নির্ধারণের সর্বোত্তম অনুশীলন

আপনার সাইটের জন্য রেফারার নীতি নির্ধারণ করার বিভিন্ন উপায় রয়েছে:

• একটি HTTP হেডার হিসাবে
• আপনার HTML এর মধ্যে
• জাভাস্ক্রিপ্ট থেকে প্রতি অনুরোধের ভিত্তিতে

আপনি বিভিন্ন পৃষ্ঠা, অনুরোধ বা উপাদানের জন্য ভিন্ন ভিন্ন নীতি নির্ধারণ করতে পারেন।

HTTP হেডার এবং মেটা এলিমেন্ট উভয়ই পেজ-লেভেলের। কোনো এলিমেন্টের কার্যকর পলিসি নির্ধারণের অগ্রাধিকার ক্রমটি নিম্নরূপ:

1. উপাদান-স্তরের নীতি
2. পৃষ্ঠা-স্তরের নীতি
3. ব্রাউজার ডিফল্ট

উদাহরণ:

index.html :

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

ইমেজটি no-referrer-when-downgrade পলিসির অধীনে অনুরোধ করা হয়েছে, এবং এই পেজ থেকে করা অন্য সব সাবরিসোর্স অনুরোধ ‘ strict-origin-when-cross-origin পলিসি অনুসরণ করে।

রেফারার পলিসি কীভাবে দেখবেন?

কোনো নির্দিষ্ট সাইট বা পেজ কোন পলিসি ব্যবহার করছে, তা নির্ধারণ করতে securityheaders.com বেশ সুবিধাজনক।

কোনো নির্দিষ্ট অনুরোধের জন্য ব্যবহৃত রেফারার পলিসি দেখতে আপনি Chrome, Edge বা Firefox-এর ডেভেলপার টুলসও ব্যবহার করতে পারেন। এই লেখাটি লেখার সময়, Safari Referrer-Policy হেডারটি দেখায় না, কিন্তু যে Referer পাঠানো হয়েছিল তা দেখায়।

আপনার ওয়েবসাইটের জন্য কোন নীতি নির্ধারণ করা উচিত?

আমরা স্পষ্টভাবে গোপনীয়তা-বর্ধক একটি নীতি, যেমন strict-origin-when-cross-origin (বা আরও কঠোর), নির্ধারণ করার জন্য দৃঢ়ভাবে সুপারিশ করছি।

'সুস্পষ্টভাবে' কেন?

আপনি যদি রেফারার পলিসি সেট না করেন, তাহলে ব্রাউজারের ডিফল্ট পলিসি ব্যবহৃত হবে—প্রকৃতপক্ষে, ওয়েবসাইটগুলো প্রায়শই ব্রাউজারের ডিফল্ট পলিসিকেই প্রাধান্য দেয়। কিন্তু এটি আদর্শ নয়, কারণ:

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

strict-origin-when-cross-origin (বা আরও কঠোর) কেন?

আপনার এমন একটি পলিসি প্রয়োজন যা নিরাপদ, গোপনীয়তা বৃদ্ধিকারী এবং কার্যকরী। "কার্যকরী" বলতে কী বোঝায় তা নির্ভর করে আপনি রেফারারের কাছ থেকে কী চান তার উপর:

• সুরক্ষিত : যদি আপনার ওয়েবসাইট HTTPS ব্যবহার করে ( না করলে, এটিকে অগ্রাধিকার দিন ), আপনি চাইবেন না যে নন-HTTPS অনুরোধের মাধ্যমে আপনার ওয়েবসাইটের URL ফাঁস হয়ে যাক। যেহেতু নেটওয়ার্কের যে কেউ এগুলো দেখতে পারে, তাই এই ফাঁসের ফলে আপনার ব্যবহারকারীরা পার্সন-ইন-দ্য-মিডল-অ্যাটাকের ঝুঁকিতে পড়বে। no-referrer-when-downgrade , strict-origin-when-cross-origin , no-referrer , এবং strict-origin পলিসিগুলো এই সমস্যার সমাধান করে।
• গোপনীয়তা বৃদ্ধি : একটি ক্রস-অরিজিন অনুরোধের জন্য, no-referrer-when-downgrade সম্পূর্ণ URL শেয়ার করে, যা গোপনীয়তার সমস্যা তৈরি করতে পারে। strict-origin-when-cross-origin এবং strict-origin শুধুমাত্র অরিজিন শেয়ার করে, এবং no-referrer কিছুই শেয়ার করে না। এর ফলে গোপনীয়তা বৃদ্ধির বিকল্প হিসেবে আপনার কাছে strict-origin-when-cross-origin , strict-origin , এবং no-referrer অবশিষ্ট থাকে।
• উপকারী : no-referrer এবং strict-origin কখনোই সম্পূর্ণ URL শেয়ার করে না, এমনকি same-origin রিকোয়েস্টের ক্ষেত্রেও। আপনার যদি সম্পূর্ণ URL-এর প্রয়োজন হয়, তাহলে strict-origin-when-cross-origin একটি ভালো বিকল্প।

এর সবকিছুর অর্থ হলো, strict-origin-when-cross-origin বেছে নেওয়া সাধারণত একটি বিচক্ষণ সিদ্ধান্ত।

উদাহরণ: strict-origin-when-cross-origin নির্ধারণ করা।

index.html :

<meta name="referrer" content="strict-origin-when-cross-origin" />

অথবা সার্ভার-সাইডে, উদাহরণস্বরূপ এক্সপ্রেসে:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

যদি strict-origin-when-cross-origin (বা আরও কঠোর) আপনার সমস্ত ব্যবহারের ক্ষেত্রগুলির জন্য উপযুক্ত না হয়, তাহলে কী হবে?

এক্ষেত্রে, একটি প্রগতিশীল পন্থা অবলম্বন করুন: আপনার ওয়েবসাইটের জন্য strict-origin-when-cross-origin মতো একটি সুরক্ষামূলক নীতি নির্ধারণ করুন এবং প্রয়োজনে, নির্দিষ্ট অনুরোধ বা HTML এলিমেন্টের জন্য আরও শিথিল নীতি গ্রহণ করুন।

উদাহরণ: উপাদান-স্তরের নীতি

index.html :

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit ক্রস-সাইট অনুরোধের জন্য document.referrer অথবা Referer হেডার সীমিত করতে পারে। বিস্তারিত দেখুন।

উদাহরণ: অনুরোধ-স্তরের নীতি

script.js :

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

আর কী কী বিবেচনা করা উচিত?

আপনার নীতি আপনার ওয়েবসাইট এবং ব্যবহারের ধরনের ওপর নির্ভর করবে, যা আপনি, আপনার দল এবং আপনার কোম্পানি নির্ধারণ করবে। যদি কিছু URL-এ শনাক্তকারী বা সংবেদনশীল তথ্য থাকে, তাহলে একটি সুরক্ষামূলক নীতি নির্ধারণ করুন।

আগত অনুরোধের জন্য সর্বোত্তম অনুশীলন

আপনার সাইট যদি আগত অনুরোধের রেফারার ইউআরএল ব্যবহার করে, তাহলে কী করতে হবে তার কিছু নির্দেশিকা এখানে দেওয়া হলো।

ব্যবহারকারীদের ডেটা সুরক্ষিত রাখুন

Referer ব্যক্তিগত, গোপনীয় বা শনাক্তকারী তথ্য থাকতে পারে, তাই এটিকে সেভাবেই বিবেচনা করুন।

আগত রেফারার পরিবর্তন হতে পারে {referer-can-change}

আগত ক্রস-অরিজিন অনুরোধ থেকে রেফারার ব্যবহার করার কিছু সীমাবদ্ধতা রয়েছে:

• অনুরোধ প্রেরণকারীর বাস্তবায়নের উপর যদি আপনার কোনো নিয়ন্ত্রণ না থাকে, তাহলে আপনি যে Referer হেডার (এবং document.referrer ) পান, সে সম্পর্কে কোনো অনুমান করতে পারবেন না। অনুরোধ প্রেরণকারী যেকোনো সময় একটি no-referrer নীতিতে, অথবা আরও সাধারণভাবে, আগের চেয়ে কঠোর কোনো নীতিতে চলে যাওয়ার সিদ্ধান্ত নিতে পারে। এর মানে হলো, আপনি Referer থেকে আগের চেয়ে কম ডেটা পাবেন।
• ব্রাউজারগুলো এখন ডিফল্ট হিসেবে ক্রমবর্ধমানভাবে ‘Referrer-Policy strict-origin-when-cross-origin ব্যবহার করছে। এর মানে হলো, যদি প্রেরক সাইটে কোনো পলিসি সেট করা না থাকে, তাহলে আগত ক্রস-অরিজিন অনুরোধগুলোতে আপনি এখন একটি সম্পূর্ণ রেফারার ইউআরএল-এর পরিবর্তে শুধুমাত্র অরিজিনটি পেতে পারেন।
• ব্রাউজারগুলো Referer পরিচালনার পদ্ধতি পরিবর্তন করতে পারে। উদাহরণস্বরূপ, ব্যবহারকারীর গোপনীয়তা রক্ষার জন্য কিছু ব্রাউজার ডেভেলপার ক্রস-অরিজিন সাবরিসোর্স অনুরোধে রেফারারকে সর্বদা অরিজিনে সীমাবদ্ধ রাখার সিদ্ধান্ত নিতে পারে।
• Referer হেডারে (এবং document.referrer ) আপনার প্রয়োজনের চেয়ে বেশি ডেটা থাকতে পারে। উদাহরণস্বরূপ, এতে একটি সম্পূর্ণ URL থাকতে পারে, যখন আপনি শুধু জানতে চান যে অনুরোধটি ক্রস-অরিজিন কিনা।

Referer বিকল্প

আপনাকে বিকল্প বিবেচনা করতে হতে পারে যদি:

• আপনার সাইটের একটি অপরিহার্য বৈশিষ্ট্য হলো এটি আগত ক্রস-অরিজিন অনুরোধগুলির রেফারার ইউআরএল ব্যবহার করে।
• আপনার সাইট এখন আর ক্রস-অরিজিন অনুরোধে রেফারার ইউআরএল-এর প্রয়োজনীয় অংশটি পাচ্ছে না। এমনটা ঘটে যখন অনুরোধকারী তার নীতি পরিবর্তন করে অথবা যখন তার কোনো নীতি সেট করা থাকে না এবং ব্রাউজারের ডিফল্ট নীতি পরিবর্তিত হয় (যেমন ক্রোম ৮৫- এর ক্ষেত্রে)।

বিকল্পগুলি নির্ধারণ করতে, প্রথমে বিশ্লেষণ করুন আপনি রেফারারের কোন অংশটি ব্যবহার করছেন।

যদি আপনার শুধু উৎস প্রয়োজন হয়

• যদি আপনি এমন কোনো স্ক্রিপ্টে রেফারার ব্যবহার করেন যেটির পেজটিতে টপ-লেভেল অ্যাক্সেস আছে, তাহলে window.location.origin একটি বিকল্প হতে পারে।
• যদি উপলব্ধ থাকে, Origin এবং Sec-Fetch-Site মতো হেডারগুলো আপনাকে Origin জানিয়ে দেয় অথবা অনুরোধটি ক্রস-অরিজিন কিনা তা বর্ণনা করে, যা আপনার ঠিক প্রয়োজন হতে পারে।

যদি আপনার URL-এর অন্যান্য উপাদানগুলির (পাথ, কোয়েরি প্যারামিটার...) প্রয়োজন হয়

• অনুরোধের প্যারামিটারগুলো আপনার প্রয়োজন মেটাতে পারে, যা আপনাকে রেফারার পার্স করার কাজ থেকে বাঁচায়।
• যদি আপনি এমন কোনো স্ক্রিপ্টে রেফারার ব্যবহার করেন যেটির পেজটিতে টপ-লেভেল অ্যাক্সেস আছে, তাহলে বিকল্প হিসেবে window.location.pathname কাজ করতে পারে। URL-এর শুধু পাথ অংশটি বের করে আর্গুমেন্ট হিসেবে পাঠান, যাতে URL প্যারামিটারে থাকা কোনো সম্ভাব্য সংবেদনশীল তথ্য স্থানান্তরিত না হয়।

যদি আপনি এই বিকল্পগুলি ব্যবহার করতে না পারেন:

• আপনার সিস্টেমগুলোকে এমনভাবে পরিবর্তন করা যায় কিনা তা পরীক্ষা করুন, যাতে অনুরোধ প্রেরক (যেমন, site-one.example ) কোনো ধরনের কনফিগারেশনের মাধ্যমে আপনার প্রয়োজনীয় তথ্য স্পষ্টভাবে সেট করে দেবে।
  • সুবিধা: আরও সুস্পষ্ট, site-one.example ব্যবহারকারীদের জন্য আরও বেশি গোপনীয়তা-সংরক্ষক, এবং ভবিষ্যতের জন্য আরও উপযোগী।
  • অসুবিধা: এর ফলে আপনার বা আপনার সিস্টেমের ব্যবহারকারীদের কাজ বেড়ে যেতে পারে।
• যাচাই করুন যে অনুরোধ প্রেরণকারী সাইটটি প্রতি-উপাদান বা প্রতি-অনুরোধের জন্য ' no-referrer-when-downgrade ' রেফারার-নীতি নির্ধারণ করতে সম্মত হতে পারে কিনা।
  • অসুবিধা: site-one.example ব্যবহারকারীদের জন্য গোপনীয়তা রক্ষায় কিছুটা ঘাটতি থাকতে পারে, এবং সব ব্রাউজারে সমর্থিত নাও হতে পারে।

ক্রস-সাইট অনুরোধ জালিয়াতি (CSRF) সুরক্ষা

অনুরোধ প্রেরণকারী একটি no-referrer নীতি নির্ধারণ করে রেফারার না পাঠানোর সিদ্ধান্ত সর্বদা নিতে পারে, এবং কোনো বিদ্বেষী ব্যক্তি এমনকি রেফারারটি নকলও করতে পারে।

আপনার প্রাথমিক সুরক্ষা হিসেবে CSRF টোকেন ব্যবহার করুন। অতিরিক্ত সুরক্ষার জন্য SameSite ব্যবহার করুন, এবং Referer এর পরিবর্তে Origin (যা POST এবং CORS অনুরোধে পাওয়া যায়) এবং Sec-Fetch-Site যদি উপলব্ধ থাকে) এর মতো হেডার ব্যবহার করুন।

লগ এবং ডিবাগ

Referer থাকা ব্যবহারকারীদের ব্যক্তিগত বা সংবেদনশীল তথ্য সুরক্ষিত রাখা নিশ্চিত করুন।

আপনি যদি শুধু অরিজিন ব্যবহার করেন, তবে বিকল্প হিসেবে Origin হেডার ব্যবহার করা যায় কিনা তা যাচাই করে দেখুন। এর মাধ্যমে আপনি রেফারার পার্স না করেই, আরও সহজ উপায়ে ডিবাগিংয়ের জন্য প্রয়োজনীয় তথ্য পেতে পারেন।

পেমেন্ট

নিরাপত্তা যাচাইয়ের জন্য পেমেন্ট প্রদানকারীরা আগত অনুরোধের Referer হেডারের উপর নির্ভর করতে পারে।

উদাহরণস্বরূপ:

• ব্যবহারকারী online-shop.example/cart/checkout এ থাকা ' Buy' বাটনে ক্লিক করেন।
• লেনদেনটি পরিচালনা করার জন্য online-shop.example payment-provider.example এ রিডাইরেক্ট করে।
• payment-provider.example এই অনুরোধের Referer টিকে মার্চেন্টদের দ্বারা সেট করা অনুমোদিত Referer মানের তালিকার সাথে মিলিয়ে দেখে। যদি এটি তালিকার কোনো এন্ট্রির সাথে না মেলে, তাহলে payment-provider.example অনুরোধটি প্রত্যাখ্যান করে। আর যদি মিলে যায়, তবে ব্যবহারকারী লেনদেনটি সম্পন্ন করতে পারেন।

পেমেন্ট প্রবাহের নিরাপত্তা যাচাইয়ের সর্বোত্তম অনুশীলন

একজন পেমেন্ট প্রোভাইডার হিসেবে, আপনি কিছু আক্রমণের বিরুদ্ধে প্রাথমিক যাচাই হিসেবে Referer ব্যবহার করতে পারেন। তবে, শুধুমাত্র Referer হেডারটি যাচাইয়ের জন্য একটি নির্ভরযোগ্য ভিত্তি নয়। অনুরোধকারী সাইট, সে বৈধ মার্চেন্ট হোক বা না হোক, একটি no-referrer পলিসি সেট করতে পারে, যা পেমেন্ট প্রোভাইডারের কাছে Referer তথ্যকে অনুপলব্ধ করে তোলে।

Referer খতিয়ে দেখলে পেমেন্ট প্রোভাইডাররা সেইসব অনভিজ্ঞ আক্রমণকারীদের ধরতে সক্ষম হতে পারে, যারা কোনো no-referrer পলিসি সেট করেনি। যদি আপনি প্রাথমিক যাচাই হিসেবে Referer ব্যবহার করেন:

• Referer সবসময় উপস্থিত থাকবে এমনটা আশা করবেন না। যদি এটি উপস্থিত থাকে, তবে এর অন্তর্ভুক্ত থাকতে পারে এমন সর্বনিম্ন ডেটা, অর্থাৎ অরিজিন-এর সাথে মিলিয়ে দেখুন।
  • অনুমোদিত Referer ভ্যালুগুলোর তালিকা নির্ধারণ করার সময়, নিশ্চিত করুন যেন শুধু origin অন্তর্ভুক্ত থাকে এবং কোনো path অন্তর্ভুক্ত না হয়।
  • উদাহরণস্বরূপ, online-shop.example এর জন্য অনুমোদিত Referer ভ্যালু online-shop.example হওয়া উচিত, online-shop.example/cart/checkout নয়। কোনো Referer আশা না করে অথবা শুধুমাত্র অনুরোধকারী সাইটের অরিজিনকে Referer ভ্যালু হিসেবে ধরে নিয়ে, আপনি মার্চেন্টের Referrer-Policy সম্পর্কে অনুমান করার ফলে উদ্ভূত ত্রুটিগুলো প্রতিরোধ করতে পারেন।
• যদি Referer অনুপস্থিত থাকে, অথবা যদি এটি উপস্থিত থাকে এবং আপনার প্রাথমিক Referer উৎস যাচাই সফল হয়, তাহলে আপনি অন্য কোনো, আরও নির্ভরযোগ্য যাচাইকরণ পদ্ধতিতে যেতে পারেন।

পেমেন্ট আরও নির্ভরযোগ্যভাবে যাচাই করার জন্য, অনুরোধকারীকে একটি অনন্য কী-এর সাথে অনুরোধের প্যারামিটারগুলো হ্যাশ করতে দিন। এরপর পেমেন্ট প্রোভাইডাররা আপনার পক্ষ থেকে একই হ্যাশ গণনা করতে পারবে এবং আপনার গণনার সাথে মিলে গেলেই কেবল অনুরোধটি গ্রহণ করবে।

যখন কোনো রেফারার পলিসিবিহীন একটি HTTP মার্চেন্ট সাইট কোনো HTTPS পেমেন্ট প্রোভাইডারে রিডাইরেক্ট করে, তখন Referer কী হয়?

HTTPS পেমেন্ট প্রোভাইডারের কাছে পাঠানো অনুরোধে কোনো Referer দেখা যায় না, কারণ কোনো ওয়েবসাইটে কোনো পলিসি সেট করা না থাকলে বেশিরভাগ ব্রাউজার ডিফল্টভাবে strict-origin-when-cross-origin অথবা no-referrer-when-downgrade ব্যবহার করে। ক্রোমের নতুন ডিফল্ট পলিসিতে পরিবর্তন এই আচরণের কোনো পরিবর্তন আনবে না।

উপসংহার

একটি সুরক্ষামূলক রেফারার পলিসি আপনার ব্যবহারকারীদের আরও বেশি গোপনীয়তা দেওয়ার একটি চমৎকার উপায়।

আপনার ব্যবহারকারীদের সুরক্ষিত রাখার বিভিন্ন কৌশল সম্পর্কে আরও জানতে, আমাদের নিরাপদ ও সুরক্ষিত সংগ্রহটি দেখুন।

সম্পদ

• 'একই-সাইট' এবং 'একই-উৎস' বোঝা
• একটি নতুন নিরাপত্তা হেডার: রেফারার নীতি (২০১৭)
• MDN-এ রেফারার-নীতি
• রেফারার হেডার: MDN-এ গোপনীয়তা এবং নিরাপত্তা সংক্রান্ত উদ্বেগ
• ক্রোম পরিবর্তন: ব্লিঙ্ক ইন্টেন্ট বাস্তবায়ন করা হবে
• ক্রোম পরিবর্তন: ব্লিঙ্ক ইন্টেন্ট চালু হতে চলেছে
• ক্রোম পরিবর্তন: স্ট্যাটাস এন্ট্রি
• ক্রোম পরিবর্তন: ৮৫ বিটা ব্লগপোস্ট
• রেফারার ট্রিমিং গিটহাব থ্রেড: বিভিন্ন ব্রাউজার কী করে
• রেফারার-পলিসি স্পেক

সকল পর্যালোচকদের - বিশেষ করে কৌস্তুভ গোবিন্দ, ডেভিড ভ্যান ক্লিভ, মাইক ওয়েস্ট, স্যাম ডাটন, রোয়ান মেরেউড, জ্যাক এবং কেসি বাস্কসকে তাদের অবদান ও মতামতের জন্য অসংখ্য ধন্যবাদ।