নিরাপত্তা, ক্রস-ব্রাউজার সামঞ্জস্য নিশ্চিত করতে এবং তৃতীয় পক্ষের কুকিগুলি পর্যায়ক্রমে আউট হয়ে গেলে ভাঙার সম্ভাবনা কমানোর জন্য কীভাবে প্রথম-পক্ষের কুকি সেট করবেন তা শিখুন।
কুকিজ ব্যবহারকারীর প্রসঙ্গের সাপেক্ষে প্রথম-পক্ষ বা তৃতীয়-পক্ষ হতে পারে; ব্যবহারকারী সেই সময়ে কোন সাইটে আছেন তার উপর নির্ভর করে। যদি কুকির নিবন্ধনযোগ্য ডোমেন এবং স্কিম বর্তমান শীর্ষ-স্তরের পৃষ্ঠার সাথে মেলে, অর্থাৎ, ব্রাউজারের ঠিকানা বারে যা প্রদর্শিত হয়, কুকিটিকে পৃষ্ঠার মতো একই সাইট থেকে বলে মনে করা হয় এবং এটি সাধারণত একটি প্রথম পক্ষের কুকি হিসাবে উল্লেখ করা হয় .
বর্তমান সাইট ব্যতীত অন্য ডোমেনের কুকিগুলিকে সাধারণত তৃতীয় পক্ষের কুকি বলা হয়৷
ভাল প্রথম পক্ষের কুকি রেসিপি
আপনি যে কুকি সেট করছেন সেটি যদি সাইট জুড়ে ব্যবহার না করা হয়, উদাহরণস্বরূপ, এটি আপনার সাইটে সেশন পরিচালনা করতে ব্যবহৃত হয় এবং এটি কখনই ক্রস-সাইট আইফ্রেমে ব্যবহার করা হয় না, সেই কুকি সর্বদা প্রথম পক্ষের প্রসঙ্গে ব্যবহৃত হয়।
ডিফল্টরূপে, কুকিগুলি সাইট জুড়ে শেয়ার করা যায়, জাভাস্ক্রিপ্ট দ্বারা অ্যাক্সেস করা যায় এবং HTTP সংযোগের মাধ্যমে পাঠানো যায়, যা কিছু গোপনীয়তা এবং নিরাপত্তা ঝুঁকির সাথে আসে। গোপনীয়তা স্যান্ডবক্স এবং অন্যান্য প্রস্তাবনা যেমন অরিজিন-বাউন্ড কুকিজের মাধ্যমে ডিফল্ট আচরণের উন্নতির জন্য চলমান কাজ চলমান থাকলেও, আপনার কুকিগুলিতে অতিরিক্ত বৈশিষ্ট্য সেট করে আপনি আজ অনেক কিছু করতে পারেন৷
নিম্নলিখিত কনফিগারেশনটি সবচেয়ে ভালো অনুশীলন, বেশিরভাগ প্রথম পক্ষের কুকির জন্য নিরাপত্তা এবং ক্রস-ব্রাউজার সামঞ্জস্য নিশ্চিত করা। এটি আপনাকে একটি নিরাপদ ভিত্তি প্রদান করবে, যা আপনি শুধুমাত্র প্রয়োজনে অনুমতিগুলি খুলতে সামঞ্জস্য করতে পারবেন। এই নিবন্ধটি কিছু নির্দিষ্ট ব্যবহারের ক্ষেত্রে রেসিপির ভিন্নতাও কভার করে।
রেসিপি
Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;
Host হল একটি ঐচ্ছিক উপসর্গ যা কিছু বৈশিষ্ট্যকে বাধ্যতামূলক করে এবং অন্যকে নিষিদ্ধ করে:
-
Secureউপস্থিত হতে হবে -
Domainঅবশ্যই বাদ দিতে হবে -
Pathহতে হবে/
Host যোগ করার সাথে, আপনি এই বৈশিষ্ট্যগুলি __Host নিয়মের সাথে সেট করা আছে কিনা তা পরীক্ষা করতে ব্রাউজারে নির্ভর করতে পারেন এবং না হলে কুকি প্রত্যাখ্যান করতে পারেন।
Secure অনিরাপদ নেটওয়ার্কে কুকিজ চুরি হওয়া থেকে রক্ষা করে কারণ এটি শুধুমাত্র HTTPS সংযোগের মাধ্যমে কুকি পাঠানোর অনুমতি দেয়। আপনি যদি আপনার সাইটটি সম্পূর্ণরূপে HTTPS-এ স্থানান্তরিত না করে থাকেন, তাহলে সেটিকে অগ্রাধিকার দিন।
Domain বৈশিষ্ট্য নির্দিষ্ট করে কোন হোস্ট একটি কুকি পেতে পারে। এটি বাদ দেওয়া কুকিকে বর্তমান ডকুমেন্ট হোস্টে সীমাবদ্ধ করে, সাবডোমেনগুলি বাদ দিয়ে: example.com এর জন্য কুকি প্রতিটি অনুরোধে example.com এ পাঠানো হবে কিন্তু images.example.com এর অনুরোধে নয়। আপনার যদি বিভিন্ন সাবডোমেনে চলমান বিভিন্ন অ্যাপ থাকে, তাহলে এটি একটি আপোসকৃত ডোমেন অন্যদের মধ্যে একটি দরজা প্রবেশ করার ঝুঁকি কমায়।
Path সেই পথ নির্দেশ করে যা ব্রাউজারের Cookie হেডার পাঠানোর জন্য অনুরোধ করা URL-এ থাকা আবশ্যক। সেটিং Path=/ মানে হল যে কুকি সেই ডোমেনের সমস্ত URL পাথে পাঠানো হয়েছে। কোন Domain এবং Path=/ এর সংমিশ্রণ কুকিকে যতটা সম্ভব উৎপত্তির সাথে আবদ্ধ করে, তাই এটি অন্যান্য ক্লায়েন্ট-সাইড স্টোরেজ যেমন LocalStorage এর মতোই আচরণ করে—এতে কোন বিভ্রান্তি নেই যে example.com/a example.com/b জন্য বিভিন্ন মান পেতে পারে example.com/b
HttpOnly অ্যাট্রিবিউট জাভাস্ক্রিপ্ট অ্যাক্সেস সীমাবদ্ধ করে আপনার সাইটে ক্ষতিকারক তৃতীয় পক্ষের স্ক্রিপ্টগুলির বিরুদ্ধে কিছু সুরক্ষা যোগ করে। এটি একটি কুকিকে শুধুমাত্র অনুরোধ শিরোনামে পাঠানোর অনুমতি দেয় এবং document.cookie ব্যবহার করে জাভাস্ক্রিপ্টে তাদের অনুপলব্ধ করে তোলে।
Max-Age একটি কুকির জীবনকে সীমিত করে কারণ ব্রাউজার সেশনগুলি বেশ দীর্ঘ সময় ধরে চলতে পারে এবং আপনি চান না যে বাসি কুকি চিরতরে ঝুলে থাকুক৷ এটি স্বল্প-মেয়াদী কুকির জন্য ভাল, যেমন ব্যবহারকারীর সেশন বা এমনকি সংক্ষিপ্ত যেমন ফর্ম জমা দেওয়ার জন্য টোকেন। Max-Age সেকেন্ডে সংজ্ঞায়িত করা হয়েছে এবং আগের উদাহরণে এটি 7776000 সেকেন্ডে সেট করা হয়েছে যা 90 দিন। এটি একটি যুক্তিসঙ্গত ডিফল্ট, যা আপনি আপনার ব্যবহারের ক্ষেত্রে উপর নির্ভর করে পরিবর্তন করতে পারেন।
SameSite=Lax কুকিকে শুধুমাত্র একই সাইটের অনুরোধে পাঠানোর জন্য সীমাবদ্ধ করে। অর্থাৎ, যেখানে অনুরোধটি বর্তমান ব্রাউজিং প্রসঙ্গের সাথে মেলে–ব্যবহারকারী বর্তমানে যে শীর্ষ স্তরের সাইটটি পরিদর্শন করছেন যা তাদের অবস্থান বারে প্রদর্শিত হয়৷ SameSite=Lax আধুনিক ব্রাউজারে ডিফল্ট কিন্তু বিভিন্ন ডিফল্ট থাকতে পারে এমন ব্রাউজার জুড়ে সামঞ্জস্যের জন্য এটি নির্দিষ্ট করা ভালো অভ্যাস। কুকিটিকে শুধুমাত্র একই-সাইট হিসাবে স্পষ্টভাবে চিহ্নিত করে, আপনি এটিকে আপনার প্রথম-পক্ষের প্রসঙ্গে সীমাবদ্ধ করছেন এবং তৃতীয় পক্ষের কুকিগুলি চলে গেলে আপনাকে সেই কুকিতে পরিবর্তন করতে হবে না।
বিভিন্ন কুকি বৈশিষ্ট্য সম্পর্কে আরও জানতে, MDN-এ Set-Cookie ডকুমেন্টেশন দেখুন।
সাবডোমেন সহ সাইটগুলির জন্য প্রথম পক্ষের কুকি রেসিপি
আপনার যদি সাবডোমেন সহ একটি সাইট থাকে এবং সেগুলি জুড়ে একটি সেশন করতে চান তবে Host উপসর্গটি খুব সীমাবদ্ধ হতে পারে। উদাহরণ স্বরূপ news.site এর বিষয়গুলির জন্য সাবডোমেন থাকতে পারে, যেমন finance.news.site এবং sport.news.site এবং আপনি তাদের সবগুলিতে একটি ব্যবহারকারীর সেশন চান৷ সেক্ষেত্রে, __Host এর পরিবর্তে __Secure উপসর্গ ব্যবহার করুন এবং Domain নির্দিষ্ট করুন।
রেসিপি
Set-Cookie:
__Secure-cookie-name=cookie-value;
Secure;
Domain=news.site;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;
Secure হল একটি ঐচ্ছিক উপসর্গ যা Host চেয়ে কম প্রয়োজনীয়তা জাহির করে: এটি শুধুমাত্র কুকিকে Secure অ্যাট্রিবিউটের সাথে সেট করা প্রয়োজন।
তৃতীয় পক্ষের ওয়েবসাইট থেকে শুরু করা অনুরোধে প্রথম পক্ষের কুকি অ্যাক্সেস সীমাবদ্ধ করা
যদিও SameSite=Lax কুকিগুলি ক্রস-সাইট সাবরিকোয়েস্টগুলিতে পাঠানো হয় না (উদাহরণস্বরূপ, তৃতীয় পক্ষের সাইটে এমবেড করা ছবি বা আইফ্রেমগুলি লোড করার সময়), সেগুলি পাঠানো হয় যখন কোনও ব্যবহারকারী মূল সাইটে নেভিগেট করে (উদাহরণস্বরূপ, যখন একটি অনুসরণ করে একটি ভিন্ন সাইট থেকে লিঙ্ক)।
আপনি SameSite=Strict সাথে তৃতীয় পক্ষের ওয়েবসাইট থেকে শুরু করা অনুরোধের সাথে কুকিজ অ্যাক্সেস সীমাবদ্ধ করতে পারেন এবং সেগুলি পাঠানোর অনুমতি দিতে পারেন না। এটি কার্যকর যখন আপনার কার্যকারিতা সম্পর্কিত কুকিজ থাকে যা সর্বদা একটি প্রাথমিক নেভিগেশনের পিছনে থাকবে, যেমন একটি পাসওয়ার্ড পরিবর্তন করা বা কেনাকাটা করা।
রেসিপি
Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Strict;