Cookie กับ Session ต่างกันอย่างไร ทำไมเว็บจำว่าคุณล็อกอินอยู่

ลองนึกภาพว่าเมื่อวานคุณล็อกอินเว็บไว้ ปิดแท็บไปทำอย่างอื่น วันนี้เปิดกลับมา เว็บยังทักชื่อคุณได้เหมือนไม่เคยจากกันไปไหน ทั้งที่คุณไม่ได้พิมพ์รหัสผ่านซ้ำเลยสักครั้ง น้องๆ ที่เพิ่งเริ่มเขียนเว็บมักถามทีมเราว่า "เว็บมันจำเราได้ยังไง" แล้วคำตอบก็มักลากไปเจอสองคำที่ถูกพูดคู่กันเสมอ คือ Cookie กับ Session

ปัญหาคือสองคำนี้ถูกใช้ปนกันจนหลายคนคิดว่าเป็นของอย่างเดียวกัน วันนี้ Superdev Academy จะพาไปดูว่าสองอย่างนี้ต่างกันตรงไหน ทำงานร่วมกันยังไง และให้ดู Header จริงที่ browser กับ server ส่งหากัน เพื่อให้คุณเห็นกับตาว่ากลไกนี้ไม่มีอะไรลึกลับเลย

ทำไมเว็บต้องมีตัวช่วยจำ ทั้งที่ HTTP ไม่จำอะไรเลย

ทุกครั้งที่ browser ขอหน้าเว็บ มันส่ง Request (คำขอ) ไปหา server แล้ว server ส่ง Response (คำตอบ) กลับมา จบแค่นั้น HTTP ถูกออกแบบให้เป็น Stateless (ไม่เก็บสถานะ) คือ server ไม่ได้จำว่า Request ก่อนหน้ามาจากใคร เอกสาร RFC 6265 ซึ่งเป็นมาตรฐานของ Cookie เองก็เขียนไว้ในบทคัดย่อว่า Cookie มีไว้สร้าง Session ที่มีสถานะ บนโปรโตคอล HTTP ที่ส่วนใหญ่ไม่มีสถานะ

ถ้าไม่มีตัวช่วย คุณจะต้องล็อกอินใหม่ทุกครั้งที่กดเปลี่ยนหน้า เพราะในสายตา server ทุก Request คือคนแปลกหน้า Cookie กับ Session คือคำตอบของปัญหานี้ แต่ทำหน้าที่คนละส่วนกัน

Cookie กับ Session ต่างกันอย่างไร: ตู้ฝากเสื้อโค้ตกับตั๋วรับของ

นึกถึงเคาน์เตอร์ฝากเสื้อโค้ตในโรงละคร คุณยื่นเสื้อให้พนักงาน พนักงานแขวนเสื้อไว้บนราวหลังเคาน์เตอร์ แล้วยื่นตั๋วใบเล็กๆ ให้คุณหนึ่งใบ ตอนกลับคุณยื่นตั๋วใบนั้น พนักงานก็หยิบเสื้อตัวที่ถูกต้องคืนให้

• Session คือราวแขวนเสื้อหลังเคาน์เตอร์ ข้อมูลจริงของคุณ เช่น คุณคือใคร ล็อกอินอยู่ไหม มีของอะไรในตะกร้า ถูกเก็บไว้ฝั่ง server

• Cookie คือตั๋วในมือคุณ ตัวมันไม่ได้มีเสื้ออยู่ข้างใน มีแค่หมายเลขที่ใช้ชี้ไปหาเสื้อ ซึ่งในโลกเว็บเรียกว่า Session ID

สรุปเป็นสองบรรทัดที่ควรจำไว้:

• Cookie: เก็บที่ Browser

• Session: เก็บที่ Server

ตั๋วหายหรือถูกขโมยเมื่อไหร่ คนที่ถือตั๋วก็ไปรับเสื้อแทนคุณได้ นี่คือเหตุผลที่เรื่องความปลอดภัยของ Cookie สำคัญมาก ซึ่งเราจะกลับมาพูดในหัวข้อ Attribute ด้านล่าง

Cookie กับ Session ไม่ได้เป็นคู่แข่งกัน ส่วนใหญ่มันทำงานด้วยกัน Cookie ถือตั๋ว Session เก็บของ

ดู Header จริง: Set-Cookie กับ Cookie

กลไกทั้งหมดเกิดขึ้นใน Header สองตัวเท่านั้น ตอนที่ server อยากให้ browser ถือตั๋ว มันส่ง Header ชื่อ Set-Cookie มากับ Response และหลังจากนั้นทุก Request ที่ไปเว็บเดียวกัน browser จะแนบ Header ชื่อ Cookie กลับไปเองโดยอัตโนมัติ

ทีมเราลองยิง curl ไปที่หน้าล็อกอินของ GitHub เมื่อวันที่ 29 กันยายน 2026 ได้ Header ตัวนี้กลับมา (ตัดค่าที่ยาวมากให้สั้นลง):

set-cookie: _gh_sess=CV5197blwy...; path=/; HttpOnly; secure; SameSite=Lax
set-cookie: logged_in=no; expires=Wed, 29 Sep 2027 04:40:57 GMT; domain=.github.com; path=/; HttpOnly; secure; SameSite=Lax

สังเกตว่าเรายังไม่ได้ล็อกอินเลย แต่ GitHub ก็ออกตั๋วให้แล้ว และ logged_in=no บอกตรงๆ ว่าตอนนี้ยังเป็นคนแปลกหน้าอยู่ ส่วนตัวแรก _gh_sess ไม่มี expires ซึ่งมีความหมาย เดี๋ยวเราจะอธิบายในหัวข้อถัดไป

เพื่อให้เห็นทั้งสองฝั่ง ทีมเราเขียน server เล็กๆ ด้วย Node.js ไม่ถึง 20 บรรทัด ให้สร้าง Session ตอนล็อกอิน แล้วลองยิงด้วย curl ผลที่ได้จริงเป็นแบบนี้:

$ curl -i localhost:3456/login
Set-Cookie: sid=fdcada48136db79c388c5993fefcdc22; Path=/; HttpOnly; Secure; SameSite=Lax
logged in

$ curl localhost:3456/me
who are you?

$ curl -H "Cookie: sid=fdcada48136db79c388c5993fefcdc22" localhost:3456/me
hello somchai

บรรทัดสุดท้ายคือหัวใจของเรื่องนี้ ค่า sid เป็นแค่ตัวอักษรสุ่ม ไม่มีชื่อ somchai อยู่ข้างในเลย ชื่อนั้นอยู่ในหน่วยความจำของ server พอเราแนบตั๋วใบเดิมไปใน Header Cookie server ก็เอาไปเปิดดูที่ราวของตัวเองแล้วรู้ทันทีว่าเราเป็นใคร ส่วน Request ที่ไม่มีตั๋ว server ตอบกลับว่าไม่รู้จัก

Attribute ที่ติดมากับตั๋ว: HttpOnly, Secure, SameSite, Expires

ข้อความหลังเครื่องหมาย ; ใน Set-Cookie เรียกว่า Attribute มันคือกติกาที่ server สั่ง browser ว่าให้ดูแลตั๋วใบนี้ยังไง ตัวที่มือใหม่ควรรู้จักมีสี่ตัว (อ้างอิงคำอธิบายจาก MDN หน้า Set-Cookie):

• Expires / Max-Age: กำหนดอายุตั๋ว Expires ระบุเป็นวันเวลา ส่วน Max-Age ระบุเป็นจำนวนวินาที ถ้าใส่ทั้งคู่ Max-Age ชนะ ถ้าไม่ใส่เลย Cookie ตัวนั้นจะกลายเป็น Session Cookie ที่ถูกลบเมื่อ browser ปิด นี่คือเหตุผลที่ _gh_sess ของ GitHub ไม่มี expires ติดมา

• HttpOnly: ห้าม JavaScript อ่าน Cookie ตัวนี้ผ่าน document.cookie ช่วยลดความเสียหายจาก XSS (การฝังสคริปต์อันตรายลงในหน้าเว็บ) เพราะต่อให้สคริปต์แปลกปลอมรันได้ ก็หยิบตั๋วไปไม่ได้ แต่ Cookie ยังถูกส่งไปกับ fetch() ตามปกติ

• Secure: ส่ง Cookie เฉพาะตอนเชื่อมต่อแบบ https: เท่านั้น (ยกเว้น localhost) กันไม่ให้ตั๋วหลุดระหว่างทางบนเครือข่ายที่ไม่เข้ารหัส

• SameSite: คุมว่าจะส่ง Cookie ไปกับ Request ที่มาจากเว็บอื่นไหม มีสามค่า Strict ส่งเฉพาะ Request จากเว็บเดียวกัน Lax ยอมส่งเพิ่มตอนผู้ใช้กดลิงก์จากเว็บอื่นเข้ามา และ None ส่งทุกกรณี แต่ต้องคู่กับ Secure เสมอ ช่วยป้องกัน CSRF (การหลอกให้ browser ส่งคำสั่งแทนคุณจากเว็บอื่น)

เรื่องค่าเริ่มต้นของ SameSite มีจุดที่ต้องระวัง ทีม Chromium ประกาศว่าตั้งแต่ Chrome 80 เป็นต้นมา Cookie ที่ไม่ระบุ SameSite จะถูกถือว่าเป็น SameSite=Lax แต่ MDN เขียนไว้ว่า "บาง browser" เท่านั้นที่ทำแบบนี้ ไม่ใช่ทุกตัว ข้อสรุปที่ปลอดภัยที่สุดจึงเป็นการใส่ SameSite เองให้ชัดทุกครั้ง อย่าฝากชีวิตไว้กับค่าเริ่มต้นของ browser ใด browser หนึ่ง

แล้ว localStorage ล่ะ ใช้เก็บแทน Cookie ไปเลยได้ไหม

ได้ และในหลายกรณีเป็นทางที่ดีกว่าด้วย MDN แนะนำเองว่าถ้าอยากเก็บข้อมูลฝั่ง client เช่น ธีมที่ผู้ใช้เลือก ให้ใช้ Web Storage API อย่าง localStorage หรือ sessionStorage แทน Cookie เพราะ Cookie ถูกส่งไปกับทุก Request ถ้ามีเยอะก็ทำให้เว็บช้าลง โดยเฉพาะบนเน็ตมือถือ ส่วน localStorage ไม่ถูกส่งไป server เลย และข้อมูลไม่มีวันหมดอายุจนกว่าจะถูกลบ ส่วน sessionStorage แม้ชื่อจะมีคำว่า session แต่เป็นคนละเรื่องกับ Session ฝั่ง server ที่เราพูดถึงในบทความนี้ มันคือ Web Storage ใน Browser ที่แยกตามแท็บ และข้อมูลจะถูกล้างเมื่อปิดแท็บหรือหน้าต่างนั้น

แต่เรื่องจะเปลี่ยนเมื่อข้อมูลนั้นคือ "ตั๋วยืนยันตัวตน" localStorage ไม่มีอะไรเทียบเท่า HttpOnly สคริปต์ใดๆ ที่รันบนหน้านั้นอ่านได้ทั้งหมด ถ้าวันหนึ่งหน้าเว็บโดน XSS ตั๋วก็หลุดทันที ในขณะที่ Session ID ใน Cookie แบบ HttpOnly ยังปลอดภัยกว่าในสถานการณ์เดียวกัน

พูดง่ายๆ คือ ข้อมูลที่ไม่ลับและ server ไม่ต้องรู้ เก็บ localStorage ได้ ส่วนตั๋วที่ใช้บอกว่าคุณคือใคร Cookie ที่ตั้ง Attribute ครบยังเป็นตัวเลือกมาตรฐาน

JWT คือทางเลือกที่ไม่ต้องมีราวแขวนเสื้อ

บางระบบไม่อยากให้ server ต้องจำ Session ของทุกคน เลยเปลี่ยนวิธีเป็นเขียนข้อมูลผู้ใช้ลงในตั๋วเองแล้วเซ็นกำกับไว้กันปลอม ตั๋วแบบนั้นคือ JWT (JSON Web Token) server แค่ตรวจลายเซ็น ไม่ต้องไปค้นราว ข้อดีข้อเสียของวิธีนี้มีรายละเอียดพอสมควร เราแยกไว้ในบทความ JWT Token คืออะไร ถ้าอยากเห็นว่าฝั่ง server ตอบกลับยังไงเวลาไม่มีตั๋วหรือตั๋วใช้ไม่ได้ ลองอ่านเรื่อง 401 ใน HTTP Status Code ต่อได้

ป้ายขอให้กดยอมรับคุกกี้ เป็นเรื่องเดียวกันไหม

เป็น Cookie ตัวเดียวกันในเชิงเทคนิค แต่เป็นคนละคำถาม Cookie ที่ใช้จำ Session ตอนล็อกอินคือสิ่งที่เว็บต้องมีเพื่อให้ทำงานได้ ส่วนป้ายที่เด้งขึ้นมาขอความยินยอมส่วนใหญ่เกี่ยวกับ Cookie ประเภทวิเคราะห์พฤติกรรมหรือโฆษณา ซึ่ง MDN จัดไว้ในกลุ่ม Tracking แยกจาก Session Management เรื่องการกดยอมรับเราเคยเขียนไว้แล้วใน การยอมรับคุกกี้คืออะไร ทำไมต้องยอมรับ บทความนี้จึงขอโฟกัสที่ฝั่งกลไกอย่างเดียว

ถ้าอยากเห็นภาพรวมว่า Session อยู่ในส่วนไหนของระบบเว็บ บทความ สำรวจโลกการพัฒนาเว็บไซต์ Front End, Back End และ Full Stack จะช่วยให้เห็นว่าราวแขวนเสื้อตัวนี้อยู่ฝั่ง Back End และถ้าพร้อมลองของจริงในภาษา Go ตอน Go กับ WebSocket Security มีตัวอย่างการใช้ Session กับการยืนยันตัวตน

สรุป: Cookie กับ Session ต่างกันอย่างไร

Cookie คือตั๋วที่ browser ถือไว้และส่งกลับไปทุก Request ส่วน Session คือข้อมูลจริงที่ server เก็บไว้และใช้ตั๋วนั้นเปิดหา ทั้งสองอย่างทำงานคู่กันเพื่อแก้ปัญหาเดียว คือ HTTP จำใครไม่ได้ ถ้าจำได้แค่ประโยคเดียว ให้จำว่าข้อมูลอยู่ที่ server ส่วน browser ถือแค่ตั๋ว และตั๋วที่ดีต้องมี HttpOnly, Secure กับ SameSite กำกับเสมอ

วิธีที่เร็วที่สุดที่จะเข้าใจเรื่องนี้จริงๆ คือเปิด DevTools ของ browser ไปที่แท็บ Network แล้วล็อกอินเว็บที่คุณใช้อยู่ทุกวัน ดูว่า Response ไหนมี Set-Cookie และ Request ถัดไปแนบ Cookie อะไรกลับไปบ้าง ห้านาทีกับการดูของจริงช่วยได้มากกว่าการอ่านนิยามซ้ำสิบรอบ

ติดตามบทความและเทคนิคสำหรับคนเริ่มต้นสายโปรแกรมเมอร์ได้ที่ช่องทางของเรา

Facebook: Superdev School (Superdev) — https://www.facebook.com/superdev.school.th

Instagram: superdevschool — https://www.instagram.com/superdevschool/

TikTok: superdevschool — https://www.tiktok.com/@superdevschool

Website: www.superdevacademy.com — https://www.superdevacademy.com/