امنیت Cookie سایت چیست؟ بررسی Secure، HttpOnly و SameSite برای جلوگیری از سرقت حساب

پاسخ کوتاه: امنیت Cookie سایت یعنی تنظیم Cookieها به شکلی که اطلاعات حساس مانند Session ID و داده‌های احراز هویت تا حد امکان در برابر سرقت، ارسال روی ارتباط ناامن و سوءاستفاده Cross-Site محافظت شوند. برای Cookieهای احراز هویت، استفاده صحیح از Secure، HttpOnly و SameSite در کنار HTTPS سراسری، محدودکردن Domain و Path، عمر مناسب Session، جلوگیری از XSS و CSRF و مدیریت صحیح Session از مهم‌ترین اقدامات دفاعی است.

بخش بزرگی از امنیت حساب کاربری در وب نه هنگام واردکردن Password، بلکه بعد از Login تعیین می‌شود.

وقتی کاربر وارد حساب می‌شود، وب‌سایت نمی‌تواند برای هر صفحه دوباره Username، Password یا کد 2FA را درخواست کند. بنابراین معمولاً یک Session ایجاد می‌شود و مرورگر اطلاعات لازم برای حفظ این نشست را در قالب یک Cookie نگهداری می‌کند.

همین Cookie ممکن است مشخص کند:

«این درخواست متعلق به کاربری است که قبلاً احراز هویت شده است.»

به همین دلیل اگر Cookie احراز هویت یا Session کاربر به‌درستی محافظت نشود، مهاجم ممکن است بتواند بدون دانستن Password از Session موجود سوءاستفاده کند.

در چنین شرایطی حتی وجود:

• Password قوی
• 2FA
• CAPTCHA
• محدودیت Login Attempt
• Passkey

نمی‌تواند به‌تنهایی ضعف Session Management را جبران کند.

Cookie در ظاهر فقط یک مقدار کوچک ذخیره‌شده در Browser است، اما در بسیاری از Applicationها ارزش امنیتی آن تقریباً مشابه یک Credential موقت است.

NIST نیز Cookieهای مرورگر را یکی از اصلی‌ترین مکانیزم‌های نگهداری Session معرفی می‌کند و توصیه می‌کند Cookieهای Session فقط روی HTTPS قابل استفاده باشند، Scope محدودی داشته باشند، در صورت امکان از JavaScript قابل دسترس نباشند، عمر مناسبی داشته باشند و از SameSite=Lax یا SameSite=Strict استفاده کنند.

در این مقاله از رخنه‌کاو بررسی می‌کنیم امنیت Cookie سایت چیست، Secure، HttpOnly و SameSite دقیقاً چه کاری انجام می‌دهند، تفاوت SameSite=Strict و Lax و None چیست، Cookie ناامن چگونه می‌تواند خطر سرقت حساب را افزایش دهد و مدیر سایت یا توسعه‌دهنده چگونه باید Cookieهای Authentication و Session را ایمن کند.

Cookie چیست؟

Cookie قطعه کوچکی از داده است که Server می‌تواند از طریق HTTP Response برای Browser ارسال کند و Browser در Requestهای بعدی آن را بر اساس قوانین مشخص دوباره به Server بفرستد.

برای مثال Server می‌تواند Response Header مفهومی زیر را ارسال کند:

Set-Cookie: session_id=abc123

Browser مقدار Cookie را ذخیره می‌کند و در Requestهای بعدی که Scope آن Cookie را Match می‌کنند، آن را برای Server ارسال می‌کند.

Cookieها کاربردهای مختلفی دارند:

• نگهداری Login Session
• ذخیره تنظیمات کاربر
• انتخاب زبان
• Shopping Cart
• Remember Me
• Analytics
• Personalization
• CSRF Token در برخی معماری‌ها
• Authentication State

همه Cookieها حساسیت یکسانی ندارند.

Cookie انتخاب زبان با Cookie مربوط به Authentication قابل مقایسه نیست.

برای مثال اگر Cookie زیر لو برود:

language=fa

معمولاً اتفاق امنیتی جدی رخ نمی‌دهد.

اما اگر Cookie دیگری حاوی Session Identifier معتبر باشد، افشای آن ممکن است به Session Hijacking یا تصاحب حساب منجر شود.

به همین دلیل Security Policy Cookie باید بر اساس نوع اطلاعات و کاربرد آن طراحی شود.

چرا Cookie برای امنیت حساب کاربران اهمیت دارد؟

فرآیند Login ساده‌شده معمولاً به شکل زیر است:

1. کاربر Username و Password را وارد می‌کند.
2. Server اطلاعات را بررسی می‌کند.
3. در صورت موفقیت، Session ایجاد می‌شود.
4. Browser یک Cookie دریافت می‌کند.
5. Cookie در Requestهای بعدی ارسال می‌شود.
6. Server بر اساس Session تشخیص می‌دهد کاربر قبلاً Login کرده است.

یعنی بعد از Login، Application دیگر در هر Request رمز عبور را بررسی نمی‌کند.

در بسیاری از سیستم‌ها چیزی که تداوم Login را ثابت می‌کند Session Secret یا Token مرتبط با Session است.

اگر مهاجم به آن دسترسی پیدا کند، ممکن است به جای قربانی شناخته شود.

NIST توضیح می‌دهد Session Secret در طول نشست، دو سوی ارتباط را به یکدیگر Bind می‌کند و Browser Cookie یکی از متداول‌ترین روش‌های نگهداری چنین Secretهایی در Web Session است.

بنابراین:

Cookie احراز هویت باید مانند یک داده حساس امنیتی مدیریت شود.

امنیت Cookie سایت چیست؟

امنیت Cookie مجموعه‌ای از تنظیمات و کنترل‌هاست که هدف آن کاهش احتمال موارد زیر است:

• سرقت Cookie
• افشای Session ID
• ارسال Cookie روی HTTP
• دسترسی JavaScript غیرضروری به Cookie
• ارسال Cookie در Requestهای Cross-Site ناخواسته
• Session Fixation
• Cookie Injection
• گسترده بودن بیش از حد Domain
• عمر بیش از حد Session
• سوءاستفاده از Subdomain
• افشای اطلاعات حساس در مقدار Cookie

سه Attribute معروف که تقریباً در هر بحث امنیت Cookie دیده می‌شوند عبارت‌اند از:

Secure

HttpOnly

SameSite

اما امنیت Cookie فقط به همین سه مورد محدود نیست.

موارد زیر نیز اهمیت دارند:

• Domain
• Path
• Expires
• Max-Age
• Cookie Prefix
• HTTPS
• Session Rotation
• Server-Side Revocation
• CSRF Protection
• XSS Prevention

بنابراین بهترین نتیجه زمانی ایجاد می‌شود که Cookie Security بخشی از یک Session Management Architecture کامل باشد.

یک Cookie امن چه شکلی دارد؟

یک نمونه مفهومی برای Session Cookie می‌تواند چیزی شبیه این باشد:

Set-Cookie: __Host-session=<random-value>; Path=/; Secure; HttpOnly; SameSite=Lax

این فقط یک مثال عمومی است و Configuration واقعی باید بر اساس معماری Application تعیین شود.

در این نمونه:

Secure

Cookie را به HTTPS محدود می‌کند.

HttpOnly

دسترسی JavaScript عادی به Cookie را محدود می‌کند.

SameSite=Lax

ارسال Cookie در بسیاری از Contextهای Cross-Site را محدود می‌کند.

Path=/

Scope مسیر Cookie را مشخص می‌کند.

و Prefix:

__Host-

محدودیت‌های بیشتری بر نحوه تعریف Cookie اعمال می‌کند.

OWASP نیز برای Session ID استفاده از ساختاری مشابه Secure; HttpOnly; SameSite=Strict و Prefixهای Cookie را به‌عنوان رویکرد دفاعی توصیه می‌کند.

Secure در Cookie چیست؟

Attribute زیر:

Secure

به Browser می‌گوید Cookie فقط روی Requestهایی که از Scheme امن HTTPS استفاده می‌کنند ارسال شود.

برای مثال:

Set-Cookie: session_id=abc123; Secure

اگر کاربر به:

https://example.com

متصل شود، Browser می‌تواند Cookie را ارسال کند.

اما هدف Secure این است که Cookie حساس روی ارتباط ساده:

http://

ارسال نشود.

OWASP استفاده از Secure برای Cookieهای Session را یکی از کنترل‌های اصلی جلوگیری از افشای Session ID روی ارتباط ناامن می‌داند.

چرا Secure مهم است؟

تصور کنید سایت شما HTTPS دارد اما Cookie Session فاقد Secure است.

ممکن است در شرایطی Browser Cookie را روی HTTP نیز ارسال کند.

اگر Connection رمزگذاری نشده باشد، احتمال افشای اطلاعات در مسیر Network افزایش پیدا می‌کند.

بنابراین:

داشتن HTTPS و داشتن Secure Cookie دو کنترل مرتبط اما مجزا هستند.

HTTPS باید کل سایت را پوشش دهد و Cookie حساس نیز باید Secure باشد.

آیا Secure خودش Cookie را رمزگذاری می‌کند؟

خیر.

این یکی از سوءبرداشت‌های رایج است.

Secure به این معنی نیست که مقدار Cookie داخل Browser رمزگذاری می‌شود.

Secure فقط نحوه ارسال Cookie را محدود می‌کند.

MDN نیز توضیح می‌دهد Secure به Browser می‌گوید Cookie را فقط روی HTTPS ارسال کند؛ اما این Attribute به‌تنهایی مانع خواندن Cookie توسط JavaScript نمی‌شود و داده Cookie را نیز به یک Secret غیرقابل دسترسی روی Device تبدیل نمی‌کند.

بنابراین Secure باید همراه کنترل‌های دیگر استفاده شود.

آیا استفاده از HTTPS بدون Secure کافی است؟

خیر.

OWASP صراحتاً هشدار می‌دهد حتی اگر Application عملاً فقط HTTPS ارائه کند، Cookie مربوط به Session باید دارای Secure باشد.

بهترین معماری:

HTTP ↓ Redirect ↓ HTTPS ↓ Session Cookie with Secure

و ترجیحاً:

HSTS

نیز بعد از Configuration صحیح HTTPS استفاده شود.

HttpOnly چیست؟

Attribute دوم:

HttpOnly

یکی از مهم‌ترین ویژگی‌های امنیتی Cookieهای Authentication است.

مثال:

Set-Cookie: session_id=abc123; HttpOnly

HttpOnly به Browser می‌گوید Cookie نباید از طریق APIهای JavaScript عادی مانند:

document.cookie

قابل خواندن باشد.

هدف اصلی این Attribute، کاهش امکان سرقت مستقیم Session Cookie در برخی سناریوهای XSS است.

OWASP استفاده از HttpOnly را برای حفاظت از محرمانگی Session ID در برابر دسترسی JavaScript توصیه می‌کند.

ارتباط HttpOnly و XSS چیست؟

فرض کنید Application دارای Cross-Site Scripting یا XSS باشد.

اگر Session Cookie توسط JavaScript قابل خواندن باشد، اجرای Script ناخواسته در Origin سایت می‌تواند محرمانگی Cookie را تهدید کند.

اما اگر Cookie دارای:

HttpOnly

باشد، JavaScript عادی نمی‌تواند مقدار Cookie را از طریق document.cookie دریافت کند.

این موضوع می‌تواند یکی از مسیرهای مستقیم سرقت Session Token را مسدود کند.

آیا HttpOnly مشکل XSS را حل می‌کند؟

خیر.

این نکته بسیار مهم است.

HttpOnly فقط خواندن مستقیم Cookie را محدود می‌کند.

اگر XSS در سایت وجود داشته باشد، Script مهاجم هنوز ممکن است بتواند:

• محتوای صفحه را بخواند.
• درخواست‌هایی از Context کاربر ارسال کند.
• اطلاعات قابل مشاهده در DOM را استخراج کند.
• عملیات‌هایی را در Session قربانی انجام دهد.

مرورگر هنگام ارسال Request معتبر ممکن است همچنان HttpOnly Cookie را خودکار همراه Request بفرستد.

بنابراین:

HttpOnly درمان XSS نیست؛ فقط یکی از لایه‌های کاهش خسارت XSS است.

OWASP نیز تأکید می‌کند HttpOnly محرمانگی Cookie را محافظت می‌کند اما وجود XSS همچنان می‌تواند امکان ارسال Request در Context کاربر را ایجاد کند.

به همین دلیل باید همزمان:

• XSS Prevention
• Output Encoding
• Sanitization
• CSP
• HttpOnly

را در نظر گرفت.

چه Cookieهایی باید HttpOnly باشند؟

Cookieهایی که JavaScript نیازی به خواندن آن‌ها ندارد و ارزش امنیتی بالایی دارند، کاندیدای اصلی HttpOnly هستند.

به‌خصوص:

• Session Cookie
• Authentication Cookie
• Login Token
• بعضی Refresh Tokenها در معماری Cookie-Based

اما همه Cookieها الزاماً نباید HttpOnly باشند.

برای مثال بعضی معماری‌های CSRF از Cookie حاوی CSRF Token استفاده می‌کنند که Frontend باید آن را بخواند و داخل Header قرار دهد.

OWASP در الگوی Cookie-to-Header نیز توضیح می‌دهد CSRF Cookie در چنین معماری‌هایی عمداً برای JavaScript قابل خواندن است.

بنابراین تصمیم باید بر اساس وظیفه Cookie گرفته شود.

قاعده مناسب این است:

اگر JavaScript نیازی به Cookie ندارد، بی‌دلیل دسترسی JavaScript به آن ندهید.

SameSite چیست؟

SameSite یکی از مهم‌ترین Attributeهای امنیتی مدرن Cookie است.

وظیفه SameSite این است که تعیین کند Browser در چه شرایطی Cookie را همراه Requestهایی که از یک Site دیگر آغاز شده‌اند ارسال کند.

سه مقدار اصلی عبارت‌اند از:

SameSite=Strict

SameSite=Lax

SameSite=None

MDN نیز این سه حالت را برای کنترل رفتار Cross-Site Cookie تعریف می‌کند.

SameSite=Strict چیست؟

Strict محدودترین Policy معمول است.

مثال:

Set-Cookie: session_id=abc; SameSite=Strict

در این حالت Browser Cookie را در Requestهای Cross-Site ارسال نمی‌کند.

این سیاست می‌تواند امنیت بسیار خوبی در برابر برخی سناریوهای CSRF ایجاد کند.

اما Strict ممکن است روی User Experience اثر بگذارد.

فرض کنید کاربر در سایت شما Login است.

سپس در Email یا سایت دیگری روی لینکی به صفحه خصوصی شما کلیک می‌کند.

چون Navigation از Site دیگری آغاز شده است، Strict ممکن است باعث شود Session Cookie همراه آن Request ارسال نشود.

در نتیجه ممکن است کاربر ابتدا به شکلی مشاهده شود که Login نیست یا مجبور شود مسیر دیگری را طی کند.

به همین دلیل Strict همیشه بهترین انتخاب برای همه سایت‌ها نیست.

SameSite=Lax چیست؟

Lax نسبت به Strict انعطاف‌پذیرتر است.

این Policy بسیاری از Cross-Site Subrequestها را محدود می‌کند، اما در برخی Top-Level Navigationهای معمول مانند دنبال‌کردن یک Link اجازه ارسال Cookie را می‌دهد.

OWASP آن را در بسیاری از سایت‌ها تعادل مناسبی بین Security و Usability می‌داند.

برای سایت‌هایی که کاربر باید بتواند از Search Engine، Email یا لینک خارجی وارد شود و Login State خود را حفظ کند، Lax می‌تواند انتخاب عملی‌تری باشد.

اما باید نکته مهمی را در نظر گرفت:

اگر Application عملیات State-Changing را از طریق GET انجام دهد، اتکا به SameSite=Lax خطرناک است.

مثلاً URL مفهومی زیر نباید صرفاً با GET حسابی را حذف کند:

/delete-account?id=123

عملیات تغییردهنده وضعیت باید از Method و کنترل‌های مناسب استفاده کند.

SameSite=None چیست؟

SameSite=None

به Browser اعلام می‌کند Cookie می‌تواند در Contextهای Cross-Site نیز ارسال شود.

این حالت برای بعضی معماری‌ها ضروری است.

مثلاً:

• Widget
• Embedded Application
• بعضی SSO Flowها
• سرویس‌های Third-Party
• iframeهای مشخص
• معماری Cross-Site واقعی

اما طبق رفتار مرورگرهای مدرن:

SameSite=None

باید همراه:

Secure

باشد.

یعنی:

SameSite=None; Secure

MDN این الزام را به‌طور مشخص ذکر می‌کند.

بنابراین استفاده از None نباید صرفاً برای «رفع خطای Cookie» انجام شود.

اگر سایت واقعاً به Cross-Site Cookie نیاز ندارد، بازکردن آن بی‌دلیل Attack Surface را افزایش می‌دهد.

Strict، Lax یا None؛ کدام بهتر است؟

پاسخ وابسته به معماری سایت است.

برای Session Cookie معمولی:

Strict در صورت امکان

و در غیر این صورت:

Lax

انتخاب‌های رایج هستند.

NIST نیز برای Session Cookie استفاده از SameSite=Lax یا SameSite=Strict را توصیه می‌کند.

آیا SameSite جایگزین CSRF Token است؟

در اغلب معماری‌ها بهتر است پاسخ را خیر بدانیم.

SameSite یک Defense in Depth مهم برای CSRF است اما محدودیت‌هایی دارد.

OWASP نیز توصیه می‌کند SameSite جایگزین کامل مکانیزم‌های استاندارد CSRF Protection در اکثر Deploymentها در نظر گرفته نشود.

راهکارهای CSRF بسته به معماری می‌توانند شامل:

• Synchronizer Token
• Double Submit Cookie
• Custom Request Header
• Origin Validation
• Fetch Metadata
• SameSite

باشند.

استفاده ترکیبی امنیت بیشتری ایجاد می‌کند.

Site و Origin یک چیز نیستند

برای درک SameSite این نکته بسیار مهم است.

در Web Security:

Origin

و:

Site

دو مفهوم متفاوت‌اند.

برای مثال:

https://app.example.com

و

https://blog.example.com

Origin یکسان ندارند.

اما ممکن است از دید SameSite در یک Site قرار بگیرند.

این یعنی نباید SameSite را با Same-Origin Policy یکسان فرض کرد.

OWASP نیز هشدار می‌دهد Subdomainهای یک Registrable Domain می‌توانند Same-Site محسوب شوند؛ بنابراین وجود یک Subdomain ضعیف یا خارج از کنترل می‌تواند در Threat Model اهمیت پیدا کند.

Secure، HttpOnly و SameSite چه تفاوتی دارند؟

این سه Attribute سه مشکل متفاوت را هدف می‌گیرند.

Secure

پرسش:

Cookie روی چه نوع Connectionی ارسال شود؟

پاسخ:

فقط HTTPS.

HttpOnly

پرسش:

آیا JavaScript بتواند مقدار Cookie را مستقیماً بخواند؟

پاسخ:

خیر.

SameSite

پرسش:

آیا Cookie در Requestهای Cross-Site ارسال شود؟

پاسخ:

بر اساس Strict، Lax یا None کنترل می‌شود.

جدول زیر تفاوت را بهتر نشان می‌دهد:

هیچ‌کدام جای دیگری را نمی‌گیرد.

Session Cookie حساس ممکن است به هر سه نیاز داشته باشد:

Secure; HttpOnly; SameSite=Lax

چرا ترکیب این سه Attribute مهم است؟

تصور کنید Cookie فقط Secure باشد.

ارتباط شبکه امن‌تر است، اما JavaScript همچنان ممکن است آن را بخواند.

حالا فرض کنید Cookie فقط HttpOnly باشد.

JavaScript مستقیم آن را نمی‌خواند، اما Cookie ممکن است روی HTTP ارسال شود.

حالا فقط SameSite داشته باشیم.

بعضی Requestهای Cross-Site محدود می‌شوند، اما Cookie ممکن است در برابر مسیرهای دیگر افشا شود.

بنابراین امنیت Cookie به ترکیب کنترل‌ها متکی است.

این همان مفهوم:

Defense in Depth

است.

Attribute Domain چیست؟

Domain

مشخص می‌کند Cookie برای چه Hostهایی قابل ارسال باشد.

اگر Domain تعریف نشود، Cookie معمولاً Host-Only خواهد بود.

اما اگر چیزی مانند:

Domain=example.com

تعریف شود، Scope می‌تواند Subdomainها را نیز درگیر کند.

برای مثال:

app.example.com

shop.example.com

blog.example.com

ممکن است تحت Domain Cookie قرار بگیرند.

MDN توصیه می‌کند Domain فقط زمانی تنظیم شود که واقعاً نیاز است و در صورت استفاده، محدودترین Domain ممکن انتخاب شود.

چرا Domain گسترده خطرناک است؟

فرض کنید Session اصلی سایت برای کل:

example.com

قابل استفاده باشد.

در این حالت Subdomainها نیز در Security Model اهمیت پیدا می‌کنند.

اگر یکی از Subdomainها:

• فراموش‌شده باشد،
• آسیب‌پذیر باشد،
• به سرویس Third-Party متصل باشد،
• توسط تیم دیگری مدیریت شود،

Risk افزایش پیدا می‌کند.

به همین دلیل Host-Only Cookie در صورت امکان معمولاً Scope کوچک‌تری دارد.

اصل مناسب:

Cookie فقط جایی در دسترس باشد که واقعاً نیاز است.

Path چیست؟

Attribute:

Path

مشخص می‌کند Browser Cookie را برای چه مسیرهایی ارسال کند.

برای مثال:

Path=/admin

باعث می‌شود Cookie روی مسیرهایی که با /admin Match می‌شوند ارسال شود.

اما نکته مهم:

Path یک Security Boundary قوی نیست.

MDN به‌صراحت تأکید می‌کند Path برای کنترل Scope ارسال Cookie است و نباید به‌عنوان مکانیزم جلوگیری از خواندن Cookie توسط Pathهای دیگر در همان Origin در نظر گرفته شود.

بنابراین از Path برای Organization و Scope استفاده کنید، نه به‌عنوان جایگزین Access Control.

Expires و Max-Age چیست؟

این Attributeها عمر Cookie را مشخص می‌کنند.

مثلاً:

Max-Age=3600

یعنی Cookie حدود یک ساعت عمر داشته باشد.

اگر:

Expires

یا:

Max-Age

وجود نداشته باشد، Cookie معمولاً Session Cookie محسوب می‌شود.

OWASP توصیه می‌کند Session IDهای حساس در صورت امکان غیر Persistent باشند تا مدت ماندگاری Credential در Client کاهش یابد.

NIST نیز توصیه می‌کند Cookie Session در زمان پایان اعتبار Session یا نزدیک به آن منقضی شود.

آیا کوتاه کردن عمر Cookie امنیت را افزایش می‌دهد؟

معمولاً بله، اما به‌تنهایی کافی نیست.

اگر Session Token دزدیده شود:

Token با عمر ۳۰ دقیقه

معمولاً پنجره سوءاستفاده کوتاه‌تری نسبت به:

Token با عمر شش ماه

دارد.

اما Expiration Browser نباید تنها راه پایان Session باشد.

Server نیز باید Session Lifetime را کنترل کند.

Client-Side Expiration با Server-Side Session Expiration فرق دارد

فرض کنید Browser Cookie را حذف کند.

اگر Server همچنان Token قبلی را معتبر بداند، نسخه دیگری از همان Token که قبلاً کپی شده ممکن است قابل استفاده باشد.

بنابراین باید دو موضوع مدیریت شوند:

Client:

Cookie Expiration

Server:

Session Invalidity

Logout امن نیز باید Session را در Server Revocation کند، نه فقط Cookie مرورگر را پاک کند.

Cookie Prefix چیست؟

مرورگرهای مدرن از Prefixهایی پشتیبانی می‌کنند که می‌توانند قوانین اضافی روی Cookie اعمال کنند.

دو Prefix بسیار مهم:

__Secure-

و

__Host-

هستند.

__Secure-

Cookie با نامی مانند:

__Secure-session

باید از Origin امن و با Attribute:

Secure

تنظیم شود.

__Host-

__Host-

محدودتر است.

برای Cookieهایی که Browser این Prefix را enforce می‌کند:

• Secure الزامی است.
• Domain نباید تعریف شود.
• Path=/ باید تنظیم شود.

MDN می‌گوید این ترکیب Cookie را به Host تنظیم‌کننده نزدیک‌تر می‌کند و امکان اشتراک گسترده با Subdomain را کاهش می‌دهد.

NIST نیز برای Browser Session Cookie در صورت امکان استفاده از __Host- را توصیه می‌کند.

__Host- چرا برای Session مناسب است؟

فرض کنید Cookie:

__Host-session

باشد.

یک Subdomain نمی‌تواند نسخه Domain-Wide این Cookie را به همان شکل معتبر تعریف کند، زیرا __Host- اجازه Domain Attribute نمی‌دهد.

این ویژگی می‌تواند در برابر بعضی سناریوهای Cookie Injection یا Session Fixation لایه دفاعی اضافه ایجاد کند.

اما باز هم:

Cookie Prefix جایگزین امنیت Subdomain و Session Management نیست.

آیا اطلاعات شخصی را داخل Cookie ذخیره کنیم؟

بهتر است Session Cookie فقط یک Identifier Opaque داشته باشد.

مثلاً:

session=8d91...

و نه:

username=aria;role=admin;email=...

NIST نیز توصیه می‌کند Session Cookie فقط یک Opaque String داشته باشد و اطلاعات شخصی Cleartext داخل آن قرار نگیرد.

حتی اگر Cookie Signed یا Encrypted باشد، باید اصل Data Minimization رعایت شود.

Cookie مرورگر محل مناسبی برای انباشتن داده حساس نیست.

Signed Cookie با Encrypted Cookie چه تفاوتی دارد؟

این دو مفهوم نباید اشتباه شوند.

Signed Cookie

Signature می‌تواند به Server کمک کند تشخیص دهد مقدار Cookie تغییر کرده است.

اما Signature الزاماً محتوا را مخفی نمی‌کند.

Encrypted Cookie

Encryption هدفش محرمانگی محتواست.

بنابراین اگر Cookie فقط Signed باشد، ممکن است Client همچنان محتوای آن را ببیند.

برای Session Authentication در بسیاری از معماری‌ها بهتر است Cookie صرفاً یک Random Opaque Identifier باشد و State اصلی در Server نگهداری شود.

آیا JWT داخل Cookie امن است؟

JWT به‌خودی‌خود پاسخ «امن» یا «ناامن» ندارد.

Security به موارد مختلف بستگی دارد:

• Algorithm
• Key Management
• Expiration
• Audience
• Issuer
• Storage
• Revocation Strategy
• Cookie Flags
• XSS
• CSRF

اگر JWT در Cookie برای Authentication استفاده می‌شود، Attributesی مانند:

• Secure
• HttpOnly
• SameSite

همچنان اهمیت دارند.

JWT ضعف Session Management را جادویی حل نمی‌کند.

Cookie و LocalStorage؛ کدام برای Token بهتر است؟

این یکی از بحث‌های رایج Web Security است.

localStorage

برای JavaScript قابل دسترس است.

بنابراین اگر Origin دارای XSS باشد، Token ذخیره‌شده در LocalStorage ممکن است مستقیماً قابل خواندن شود.

OWASP در Session Management Cheat Sheet توصیه می‌کند Authentication Token، Session ID، JWT و Refresh Token در localStorage یا sessionStorage ذخیره نشوند و در معماری Browser-Based، HttpOnly Cookie یا الگوهایی مانند Backend-for-Frontend بررسی شوند.

اما Cookie نیز مشکل خودش را دارد:

Browser آن را خودکار همراه Request ارسال می‌کند.

در نتیجه CSRF باید مدیریت شود.

بنابراین معماری امن معمولاً نیازمند:

HttpOnly Cookie + SameSite + CSRF Protection

است.

امنیت Cookie در برابر XSS

برای کاهش Risk XSS:

• Cookie Session باید HttpOnly باشد.
• Output Encoding انجام شود.
• ورودی HTML Sanitization شود.
• Dangerous Sinkها حذف شوند.
• CSP مناسب بررسی شود.
• Dependencyها به‌روز باشند.
• Scriptهای Third-Party محدود شوند.

نکته مهم:

Secure Cookie بدون Secure Coding کافی نیست.

اگر XSS فعال باشد، مهاجم ممکن است حتی بدون سرقت مستقیم Cookie از Session کاربر سوءاستفاده کند.

امنیت Cookie در برابر CSRF

Cookie Authentication به‌صورت خودکار توسط Browser ارسال می‌شود.

همین ویژگی می‌تواند زمینه CSRF را ایجاد کند.

برای دفاع:

• SameSite
• CSRF Token
• Origin Checking
• Fetch Metadata
• Reauthentication

باید بر اساس معماری بررسی شوند.

برای عملیات حساس مانند:

• تغییر Password
• تغییر Email
• برداشت مالی
• حذف حساب
• غیرفعال‌کردن 2FA

حتی وجود Session معتبر ممکن است کافی نباشد و Step-Up Authentication مناسب باشد.

SameSite و Clickjacking

SameSite فقط به CSRF مربوط نیست.

OWASP اشاره می‌کند SameSite=Lax و Strict می‌توانند در بعضی سناریوهای Clickjacking که نیازمند Session احراز هویت‌شده داخل iframe هستند نیز یک لایه دفاعی ایجاد کنند.

اما دفاع اصلی Clickjacking بهتر است با:

Content-Security-Policy: frame-ancestors

یا در معماری‌های قدیمی‌تر:

X-Frame-Options

انجام شود.

باز هم SameSite یک Defense in Depth است.

آیا Cookie Security جلوی Session Hijacking را می‌گیرد؟

می‌تواند Risk را به‌شدت کاهش دهد، اما تضمین کامل نیست.

Session Hijacking ممکن است از مسیرهای مختلف رخ دهد:

• XSS
• Malware
• Browser Extension مخرب
• Token Leak
• Logging اشتباه
• Session Fixation
• Insecure Transport
• Endpointهای ناامن

Cookie Security بعضی مسیرها را محدود می‌کند.

مثلاً:

Secure → کاهش Exposure روی HTTP

HttpOnly → کاهش سرقت مستقیم توسط JavaScript

SameSite → کاهش Cross-Site Requestهای ناخواسته

اما اگر Endpoint کاربر آلوده باشد، ممکن است Cookie Security نتواند همه خطرها را حذف کند.

مهم‌ترین اشتباهات امنیت Cookie سایت

اشتباه اول: Session Cookie بدون Secure

اگر Cookie Authentication روی HTTPS استفاده می‌شود، نبود Secure یک Configuration ضعیف است.

اشتباه دوم: Cookie حساس بدون HttpOnly

اگر Frontend واقعاً نیاز ندارد Session Token را بخواند، قابل دسترس گذاشتن آن برای JavaScript Attack Surface را افزایش می‌دهد.

اشتباه سوم: SameSite=None بدون نیاز

Cross-Site Cookie باید فقط زمانی فعال شود که معماری واقعاً آن را لازم دارد.

اشتباه چهارم: Domain بیش از حد گسترده

استفاده بی‌دلیل از:

Domain=example.com

می‌تواند Subdomainهای بیشتری را وارد Security Boundary کند.

اشتباه پنجم: Session بسیار طولانی

Remember Me دائمی یا Session چندماهه می‌تواند پنجره سوءاستفاده از Token دزدیده‌شده را افزایش دهد.

اشتباه ششم: ذخیره اطلاعات حساس داخل Cookie

Session Cookie بهتر است Opaque باشد.

اشتباه هفتم: اعتماد کامل به SameSite

SameSite جایگزین تمام CSRF Defenseها نیست.

اشتباه هشتم: تصور اینکه HttpOnly یعنی XSS دیگر مهم نیست

HttpOnly فقط Cookie Reading را محدود می‌کند.

اشتباه نهم: تصور اینکه Secure یعنی Cookie رمزگذاری شده است

Secure فقط انتقال را به HTTPS محدود می‌کند.

اشتباه دهم: Logout فقط Cookie را حذف کند

Session باید سمت Server نیز Revoked شود.

امنیت Cookie در WordPress

WordPress برای Authentication به Cookie وابسته است.

طبق مستندات رسمی WordPress، پس از Login چند Cookie مهم استفاده می‌شوند.

از جمله:

wordpress_[hash]

و:

wordpress_logged_in_[hash]

WordPress همچنین در اتصال امن از Cookie مرتبط با Authentication امن استفاده می‌کند و استفاده از HTTPS برای Login قویاً توصیه شده است.

wordpress_[hash] چیست؟

این Cookie برای Authentication در بخش مدیریتی WordPress استفاده می‌شود.

wordpress_logged_in_[hash] چیست؟

این Cookie به WordPress کمک می‌کند تشخیص دهد کاربر در Frontend Login است و چه Userی است.

wordpress_sec_[hash] چیست؟

مستندات فعلی WordPress آن را Cookie احراز هویت امن برای Login از طریق HTTPS معرفی می‌کنند.

این موضوع نشان می‌دهد امنیت Cookie مستقیماً بخشی از امنیت Login وردپرس است.

عمر Cookie ورود WordPress چقدر است؟

طبق مستندات فعلی WordPress:

Login معمولی به‌طور پیش‌فرض Session محدودی دارد و Backend expiration معمولاً دو روز در نظر گرفته می‌شود.

اگر:

Remember Me

فعال شود، مدت پیش‌فرض می‌تواند تا حدود ۱۴ روز افزایش یابد.

این مقادیر از طریق Hook:

auth_cookie_expiration

قابل تغییر هستند.

افزایش عمر Login باید آگاهانه انجام شود.

برای حساب Administrator، Session بسیار طولانی همیشه انتخاب مناسبی نیست.

HTTPS برای WordPress چرا حیاتی است؟

WordPress Developer Documentation استفاده از HTTPS را برای کاهش احتمال سرقت Cookieهای Authentication و Headerهای احراز هویت توصیه می‌کند.

مدیر WordPress باید مطمئن شود:

• Login روی HTTPS است.
• wp-admin روی HTTPS است.
• Frontend نیز HTTPS دارد.
• HTTP به HTTPS Redirect می‌شود.
• Mixed Content مشکل جدی ایجاد نمی‌کند.
• Reverse Proxy تنظیم درست دارد.

گزینه:

FORCE_SSL_ADMIN

نیز برای اجبار SSL در Administration Screen قابل استفاده است.

آیا باید COOKIE_DOMAIN وردپرس را تغییر دهیم؟

فقط در صورت نیاز مشخص.

WordPress امکان تعریف Cookie Domain را دارد.

اما تعریف Domain گسترده صرفاً برای «حل مشکل Login» بدون فهم Architecture می‌تواند Scope Cookie را تغییر دهد.

اگر سایت ساده‌ای روی یک Host دارید، بهتر است قبل از هر تغییر بدانید چرا به Domain سفارشی نیاز دارید.

در معماری Multi-Subdomain یا Multisite جزئیات متفاوت‌اند و Configuration باید دقیق بررسی شود.

امنیت Cookie در WooCommerce

WooCommerce علاوه بر WordPress Authentication ممکن است Cookieهایی برای:

• Cart
• Session
• Customer State

استفاده کند.

همه این Cookieها ارزش امنیتی یکسانی ندارند.

مثلاً Shopping Cart Cookie با Administrator Authentication Cookie یکی نیست.

اما در فروشگاه اینترنتی، Session Security اهمیت بالایی دارد زیرا حساب مشتری ممکن است حاوی:

• اطلاعات سفارش
• نام
• آدرس
• تلفن
• Download
• اطلاعات حساب

باشد.

برای WooCommerce:

• HTTPS سراسری
• Secure Authentication Cookie
• Session Lifetime مناسب
• XSS Prevention
• CSRF Protection
• Plugin Update
• 2FA برای Administrator

اهمیت زیادی دارند.

آیا همه Cookieهای سایت باید Secure و HttpOnly باشند؟

نه الزاماً.

برای مثال:

Cookie‌ای که JavaScript باید برای تنظیم Theme بخواند، ممکن است HttpOnly نباشد.

Cookie Public Preference نیز Security Requirement متفاوتی دارد.

در عوض:

Session Authentication Cookie

معمولاً باید با Policy بسیار سخت‌گیرانه‌تری مدیریت شود.

بهتر است Cookieها Inventory شوند.

جدولی مانند:

این روش از تنظیم کورکورانه جلوگیری می‌کند.

چگونه Cookieهای سایت را بررسی کنیم؟

بدون انجام هیچ حمله‌ای می‌توان Cookie Configuration سایت خود را بررسی کرد.

در Browser Developer Tools معمولاً بخش Storage یا Application امکان مشاهده Cookieها را می‌دهد.

موارد مهمی که باید Audit شوند:

• Name
• Domain
• Path
• Expires
• Secure
• HttpOnly
• SameSite

همچنین Response Header:

Set-Cookie

باید بررسی شود.

هدف Security Review این است که مشخص شود Cookieهای حساس Policy مناسبی دارند یا خیر.

چک‌لیست بررسی Cookie

برای هر Cookie سؤال‌های زیر را بپرسید:

آیا این Cookie واقعاً لازم است؟

Cookie غیرضروری را حذف کنید.

آیا داده حساس داخل آن قرار دارد؟

در صورت امکان Cookie باید Opaque Identifier باشد.

آیا Secure فعال است؟

برای Cookieهای حساس روی HTTPS، بله.

آیا HttpOnly لازم است؟

اگر JavaScript نیازی به Cookie ندارد، معمولاً بله.

SameSite چیست؟

Strict، Lax یا None باید آگاهانه انتخاب شود.

Domain چقدر گسترده است؟

حداقل Scope لازم انتخاب شود.

Path مناسب است؟

Scope بی‌دلیل گسترده نباشد.

Cookie چقدر عمر دارد؟

Lifetime باید با Risk متناسب باشد.

آیا Logout آن را واقعاً باطل می‌کند؟

Server-Side Revocation بررسی شود.

یک Configuration پیشنهادی برای Session Cookie معمولی

برای یک Application معمولی که Session فقط روی یک Host نیاز است:

Set-Cookie: __Host-session=<random>; Secure; HttpOnly; SameSite=Lax; Path=/

ممکن است Baseline مناسبی باشد.

برای یک پنل بسیار حساس که Cross-Site Navigation مهم نیست:

SameSite=Strict

می‌تواند بررسی شود.

اما این‌ها Template هستند.

باید Login Flow، OAuth، SSO، iframe و Integrationهای خارجی تست شوند.

Configuration اشتباه SameSite چگونه سایت را خراب می‌کند؟

امنیت فقط سخت‌گیرانه‌تر کردن Policy نیست.

اگر بدون Test از:

Lax

به:

Strict

بروید، ممکن است Flowهایی مانند:

• SSO
• Payment Return
• External Authentication
• Deep Link
• Cross-Site Redirect

دچار مشکل شوند.

در مقابل اگر برای حل سریع مشکل همه Cookieها را:

SameSite=None

کنید، امنیت Cross-Site را بی‌دلیل کاهش داده‌اید.

راه درست:

1. Flowها را شناسایی کنید.
2. Cookieها را دسته‌بندی کنید.
3. Policy مناسب انتخاب کنید.
4. در Staging تست کنید.
5. سپس Deploy کنید.

Cookie و درگاه پرداخت

این مورد برای فروشگاه‌های اینترنتی اهمیت زیادی دارد.

کاربر ممکن است:

Shop → Payment Gateway → Shop

را طی کند.

بازگشت از Payment Provider یک Cross-Site Navigation است.

بنابراین اگر Session یا State پرداخت با SameSite بسیار سخت‌گیرانه طراحی شود، Flow ممکن است تحت تأثیر قرار گیرد.

اما راه‌حل این نیست که تمام Cookieها None شوند.

Payment Flow باید جداگانه طراحی و تست شود.

Cookie و OAuth / SSO

OAuth و SSO نیز Redirectهای Cross-Site دارند.

مثلاً:

Application → Identity Provider → Application

بنابراین SameSite Policy باید با Authentication Flow سازگار باشد.

در این شرایط از:

• State Parameter
• PKCE
• Nonce
• Session Binding
• Cookie Policy مناسب

استفاده می‌شود.

هیچ Attribute واحدی جای طراحی صحیح Authentication Protocol را نمی‌گیرد.

Cookie و Subdomain Takeover

اگر Cookie برای Parent Domain Scope شده باشد، امنیت Subdomainها اهمیت بیشتری پیدا می‌کند.

مثلاً:

Domain=example.com

در حالی که:

old.example.com

به سرویس قدیمی یا Third-Party اشاره دارد.

یک Subdomain ضعیف می‌تواند Threat Model Cookie را تغییر دهد.

به همین دلیل Cookie Prefix:

__Host-

و Host-Only Cookie در موارد مناسب ارزشمند هستند.

Cookie و Session Fixation

Session Fixation زمانی رخ می‌دهد که Session Identifier از قبل برای مهاجم شناخته‌شده باشد و Application پس از Login همان Session را معتبر نگه دارد.

Cookie Flags کمک می‌کنند، اما کنترل حیاتی این است:

Session ID بعد از Authentication تغییر کند.

قبل از Login:

Session A

بعد از Login:

Session B

و Session A دیگر به Session احراز هویت‌شده تبدیل نشود.

OWASP Session Rotation پس از تغییر Privilege را یکی از کنترل‌های اصلی Session Management می‌داند.

آیا IP Binding امنیت Cookie را بیشتر می‌کند؟

Bind کردن Session به IP می‌تواند در ظاهر جذاب باشد، اما IP کاربران تغییر می‌کند.

نمونه:

• اینترنت موبایل
• VPN
• Wi-Fi
• Proxy
• Carrier NAT
• IPv6

به همین دلیل IP بهتر است در بسیاری از سیستم‌ها یک Risk Signal باشد نه Authentication Factor قطعی.

برای مثال:

Cookie معتبر

• IP جدید
• Device جدید
• تغییر Password

می‌تواند باعث Reauthentication شود.

این طراحی از قطع بی‌دلیل Session کاربران جلوگیری می‌کند.

Reauthentication چه ارتباطی با Cookie دارد؟

Cookie معتبر نباید همیشه به معنی Trust نامحدود باشد.

برای عملیات حساس بهتر است مجدداً هویت کاربر بررسی شود.

مثلاً:

• تغییر Password
• حذف 2FA
• تغییر Email
• ایجاد API Key
• برداشت
• حذف حساب
• تغییر Role

این کار باعث می‌شود اگر Session Cookie سرقت شده باشد، مهاجم برای انجام مهم‌ترین عملیات با یک Barrier اضافی مواجه شود.

Logout امن برای Cookie چگونه است؟

Logout باید دو بخش داشته باشد.

Client Side

Cookie پاک یا Expire شود.

Server Side

Session مربوطه Invalid شود.

اگر فقط Cookie Browser حذف شود ولی Server همچنان Token را معتبر بداند، نسخه دزدیده‌شده Cookie ممکن است همچنان کار کند.

به همین دلیل:

Logout ≠ Delete Cookie Only

Logout از همه دستگاه‌ها

برای حساب حساس بهتر است کاربران بتوانند:

• Sessionهای فعال را ببینند.
• Deviceهای مشکوک را Logout کنند.
• همه Sessionها را Revocation کنند.

این قابلیت در Incident Response بسیار ارزشمند است.

تغییر Password چه اثری باید روی Cookie داشته باشد؟

در سیستم امن، تغییر Password باید باعث بررسی Sessionهای فعال شود.

بسته به Risk می‌توان:

• همه Sessionها را باطل کرد.
• Session فعلی را نگه داشت و بقیه را حذف کرد.
• Reauthentication انجام داد.

WordPress نیز Authentication Cookie را به Credential State کاربر مرتبط می‌کند و تغییر Password می‌تواند Cookieهای قبلی را Invalid کند.

Cookie Security و 2FA

2FA جلوی بسیاری از Account Takeoverها را می‌گیرد.

اما Cookie دزدیده‌شده ممکن است مربوط به Sessionی باشد که قبلاً 2FA را گذرانده است.

بنابراین:

2FA ≠ Session Security

هر دو لازم‌اند.

مدل مناسب:

Secure Login + Secure Cookie + Secure Session + Reauthentication

Cookie Security و WAF

WAF می‌تواند بعضی Configurationهای Cookie را بررسی یا در شرایط خاص Rewrite کند.

OWASP اشاره می‌کند WAFها می‌توانند برای enforce کردن Attributeهایی مانند Secure و HttpOnly به‌عنوان لایه مکمل استفاده شوند.

اما WAF جایگزین Application Fix نیست.

اگر Developer بتواند Cookie را درست تنظیم کند، بهتر است Configuration در Source یا Framework صحیح باشد.

Cookie Security در Reverse Proxy و CDN

وقتی Application پشت:

• Cloud Proxy
• CDN
• Load Balancer
• Reverse Proxy

قرار دارد، تشخیص HTTPS ممکن است پیچیده شود.

اگر Backend تصور کند Request از HTTP آمده است، ممکن است Secure Cookie را اشتباه تنظیم کند.

بنابراین:

Trusted Proxy

و:

Forwarded Scheme

باید درست Configuration شوند.

این مسئله در WordPress پشت Reverse Proxy نیز می‌تواند باعث Login Loop و Cookie مشکلات شود.

Framework پیش‌فرض را کورکورانه قبول نکنید

Frameworkهای مدرن معمولاً Session Security خوبی دارند، اما Defaultها همیشه مناسب همه Applicationها نیستند.

بعد از نصب Framework بررسی کنید:

• Secure default چیست؟
• SameSite default چیست؟
• HttpOnly فعال است؟
• Session Lifetime چقدر است؟
• Secret چگونه تولید می‌شود؟
• Production Mode چیست؟

امنیت باید Explicit باشد.

Browser Default برای SameSite را کافی ندانید

برخی Browserهای مدرن Cookie بدون SameSite صریح را مانند Lax رفتار می‌دهند.

اما بهتر است Application به Browser Default تکیه نکند.

OWASP نیز توصیه می‌کند SameSite برای Session Cookie به‌صورت Explicit تنظیم شود زیرا رفتار پیش‌فرض میان Browserها و Versionها ممکن است تفاوت داشته باشد.

یعنی:

خوب:

SameSite=Lax

کمتر مطلوب:

«هرچه Browser خودش خواست.»

آیا Secure Cookie روی localhost کار می‌کند؟

Browserها برای Development روی localhost استثناهایی دارند.

MDN اشاره می‌کند محدودیت HTTPS مربوط به Secure روی localhost ممکن است متفاوت اعمال شود.

اما این رفتار Development نباید باعث شود Production بدون HTTPS واقعی Deploy شود.

Production باید TLS معتبر داشته باشد.

آیا Cookie را می‌توان در Log ذخیره کرد؟

Session Cookie کامل نباید در Log ذخیره شود.

مثلاً ثبت Header کامل:

Cookie: session=...

می‌تواند Secret را وارد Logging Infrastructure کند.

Log ممکن است توسط:

• Support
• Developer
• SIEM
• Backup
• Monitoring Service

قابل مشاهده باشد.

در Log بهتر است Cookie Secret Mask یا Redact شود.

Cookie Security در Analytics و Third-Party Script

Third-Party JavaScript داخل Origin سایت می‌تواند Security Risk ایجاد کند.

اگر Cookie Session HttpOnly باشد، Script Third-Party نمی‌تواند مستقیماً آن را از document.cookie بخواند.

این یکی دیگر از مزایای HttpOnly است.

اما Third-Party Script همچنان می‌تواند خطرات دیگری داشته باشد.

بنابراین:

• Scriptهای غیرضروری حذف شوند.
• CSP بررسی شود.
• Vendorها محدود شوند.
• Integrity و Supply Chain جدی گرفته شود.

تفاوت First-Party و Third-Party Cookie

First-Party Cookie معمولاً در Context همان سایتی استفاده می‌شود که کاربر در حال مشاهده آن است.

Third-Party Cookie در Context Cross-Site قرار می‌گیرد.

Browserهای مدرن محدودیت‌های بیشتری برای Third-Party Cookie اعمال کرده‌اند و فناوری‌هایی مانند Partitioned Cookies نیز توسعه پیدا کرده‌اند.

اما برای Session Authentication سایت اصلی، هدف معمولاً استفاده از Cookie با Scope محدود و First-Party است.

Partitioned Cookie چیست؟

Attribute:

Partitioned

برای سناریوهایی طراحی شده است که Cookie در Context Third-Party استفاده می‌شود اما Storage آن بر اساس Top-Level Site Partition شود.

MDN توضیح می‌دهد Partitioned Cookie باید همراه Secure استفاده شود.

این قابلیت برای Session عادی سایت اصلی معمولاً لازم نیست و بیشتر در معماری‌های Embedded و Cross-Site جدید مطرح است.

چه زمانی SameSite=None واقعاً لازم است؟

نمونه‌های احتمالی:

• Application داخل iframe روی Domain دیگر
• بعضی Identity Flowها
• Widget Third-Party
• Cross-Site Embedded Service

قبل از انتخاب None باید سؤال کنید:

آیا Browser واقعاً باید این Cookie را در Cross-Site Context ارسال کند؟

اگر پاسخ خیر است:

Strict یا Lax بهتر است بررسی شود.

چک‌لیست امنیت Cookie برای توسعه‌دهنده

برای Cookieهای Authentication این موارد را بررسی کنید:

• Cookie روی HTTPS تنظیم می‌شود؟
• Secure فعال است؟
• HttpOnly فعال است؟
• SameSite صریح تعیین شده؟
• SameSite=None فقط در صورت نیاز استفاده شده؟
• None همراه Secure است؟
• Domain تا حد ممکن محدود است؟
• می‌توان Domain را حذف و Host-Only کرد؟
• Path مناسب است؟
• Lifetime منطقی است؟
• Token Random و غیرقابل پیش‌بینی است؟
• اطلاعات شخصی Cleartext داخل Cookie نیست؟
• Cookie داخل URL قرار نمی‌گیرد؟
• Cookie داخل Log ذخیره نمی‌شود؟
• Session پس از Login Rotate می‌شود؟
• Logout Session سمت Server را Invalid می‌کند؟
• Password Change Session Policy دارد؟
• Reauthentication برای عملیات حساس انجام می‌شود؟
• CSRF Protection مستقل وجود دارد؟
• XSS Prevention اجرا شده؟
• Cookie Prefix قابل استفاده است؟

چک‌لیست امنیت Cookie برای مدیر WordPress

اگر سایت WordPress دارید:

• HTTPS روی تمام سایت فعال باشد.
• HTTP به HTTPS Redirect شود.
• wp-admin فقط روی HTTPS باشد.
• Cookieهای Authentication را در Browser بررسی کنید.
• Pluginهای Login و Security معتبر باشند.
• Session Lifetime بی‌دلیل افزایش نیابد.
• Administratorها از 2FA استفاده کنند.
• Administrator غیرضروری حذف شود.
• XSS در Pluginهای اختصاصی بررسی شود.
• Pluginهای بلااستفاده حذف شوند.
• Cache نباید صفحات خصوصی را عمومی کند.
• Reverse Proxy باید HTTPS را درست تشخیص دهد.
• Sessionهای مشکوک Revocation شوند.
• Secretها یا Cookieها داخل Log قرار نگیرند.

چک‌لیست سریع Secure، HttpOnly و SameSite

اشتباهات رایج مدیران سایت در امنیت Cookie

«سایت SSL دارد، پس Cookie امن است»

اشتباه است.

Cookie باید Secure هم باشد و Session Architecture نیز صحیح باشد.

«HttpOnly فعال کردم، پس XSS خطر ندارد»

اشتباه است.

XSS همچنان بسیار خطرناک است.

«SameSite=None جدیدتر است، پس بهتر است»

خیر.

None به معنی Cross-Site Access بیشتر است.

«همه Cookieها باید Strict باشند»

نه.

بعضی Flowها به Cross-Site Navigation نیاز دارند.

«Cookie با Path محدود کاملاً امن است»

Path Security Boundary قابل اتکا نیست.

«Remember Me را یک سال می‌کنیم چون کاربران راحت‌ترند»

User Experience مهم است، اما عمر Session باید با Risk متناسب باشد.

«اگر Cookie پاک شد، Session تمام است»

Server نیز باید Session را Invalid کند.

معماری پیشنهادی برای حفاظت از حساب کاربران

امنیت Account را می‌توان به چند لایه تقسیم کرد.

لایه اول: Transport

HTTPS HSTS Secure Cookie

لایه دوم: Cookie

HttpOnly SameSite Domain محدود Path مناسب Prefix

لایه سوم: Session

Random Token Rotation Timeout Server Revocation

لایه چهارم: Application

XSS Prevention CSRF Protection Secure Coding

لایه پنجم: Authentication

Password 2FA Passkey Reauthentication

لایه ششم: Detection

Session Monitoring Login Alert Device Management Security Logging

امنیت واقعی زمانی شکل می‌گیرد که این لایه‌ها کنار هم قرار گیرند.

اگر Cookie سایت ناامن باشد چه اتفاقی ممکن است بیفتد؟

نتیجه بستگی به نوع Cookie دارد.

برای یک Preference Cookie شاید فقط تنظیم ظاهری کاربر تغییر کند.

اما برای Authentication Cookie پیامدها می‌توانند جدی باشند:

• Session Hijacking
• Account Takeover
• دسترسی به اطلاعات کاربر
• تغییر تنظیمات حساب
• سوءاستفاده از Account
• دسترسی مدیریتی در حساب‌های Privileged

بنابراین اولویت اصلاح Cookieها باید بر اساس Sensitivity تعیین شود.

اگر Session Cookie سرقت شد چه کنیم؟

فرآیند Incident Response می‌تواند شامل این موارد باشد:

Session را Revocation کنید

تمام Sessionهای مشکوک پایان داده شوند.

Password را بررسی و در صورت نیاز تغییر دهید

اگر Credential Compromise نیز محتمل است.

MFA را بررسی کنید

مطمئن شوید مهاجم تنظیم 2FA را تغییر نداده باشد.

Root Cause را پیدا کنید

ممکن است مشکل از:

• XSS
• Malware
• Token Leak
• HTTP
• Logging
• Extension مخرب

باشد.

Logها را بررسی کنید

Activity حساب مشخص شود.

Session Policy را اصلاح کنید

فقط Cookie جدید صادرکردن بدون اصلاح علت اصلی کافی نیست.

آیا امنیت Cookie فقط وظیفه توسعه‌دهنده است؟

خیر.

افراد مختلف نقش دارند:

Developer → Cookie Flags

DevOps → HTTPS و Reverse Proxy

SysAdmin → TLS و Server

Security Team → Review و Monitoring

WordPress Admin → Plugin، HTTPS و Session Management

Hosting Provider → Infrastructure

به همین دلیل Cookie Security یک مسئله End-to-End است.

سؤالات متداول درباره امنیت Cookie

Secure در Cookie چیست؟

Secure به Browser اعلام می‌کند Cookie فقط روی Connection امن HTTPS ارسال شود. این ویژگی برای Cookieهای Authentication و Session اهمیت زیادی دارد و خطر ارسال Credential روی HTTP را کاهش می‌دهد.

HttpOnly چیست؟

HttpOnly دسترسی JavaScript معمولی به Cookie را محدود می‌کند. این ویژگی می‌تواند احتمال سرقت مستقیم Session Cookie در برخی حملات XSS را کاهش دهد، اما جایگزین جلوگیری از XSS نیست.

SameSite چیست؟

SameSite مشخص می‌کند Browser در چه شرایطی Cookie را همراه Requestهای Cross-Site ارسال کند. سه مقدار اصلی آن Strict، Lax و None هستند.

SameSite=Strict بهتر است یا Lax؟

Strict محدودیت امنیتی بیشتری دارد، اما ممکن است بعضی Navigationها و Authentication Flowها را تحت تأثیر قرار دهد. Lax برای بسیاری از سایت‌های معمولی تعادل مناسبی بین Security و Usability ایجاد می‌کند.

آیا SameSite=None ناامن است؟

خود None الزاماً آسیب‌پذیری نیست، اما Cookie را برای Cross-Site Context قابل استفاده می‌کند. فقط زمانی باید استفاده شود که معماری واقعاً به آن نیاز دارد و باید همراه Secure باشد.

آیا Secure و HttpOnly جلوی سرقت حساب را می‌گیرند؟

آن‌ها Risk را کاهش می‌دهند اما کافی نیستند. Session Rotation، HTTPS، XSS Prevention، CSRF Protection، Timeout، Revocation و Reauthentication نیز اهمیت دارند.

آیا WordPress از Cookie برای Login استفاده می‌کند؟

بله. WordPress برای Authentication و تشخیص وضعیت Login کاربران از Cookieهایی مانند wordpress_[hash] و wordpress_logged_in_[hash] استفاده می‌کند. به همین دلیل امنیت HTTPS و Session برای WordPress اهمیت بالایی دارد.

جمع‌بندی؛ برای افزایش امنیت Cookie سایت چه کنیم؟

امنیت Cookie یکی از بخش‌هایی است که در ظاهر ساده به نظر می‌رسد اما مستقیماً با امنیت Session و حساب کاربران ارتباط دارد.

پس از اینکه کاربر با Password، 2FA یا Passkey وارد سایت شد، Application باید راهی برای تشخیص Requestهای بعدی او داشته باشد. در بسیاری از Web Applicationها این وظیفه از طریق Session Cookie انجام می‌شود.

به همین دلیل Session Cookie باید مانند یک Credential موقت محافظت شود.

سه Attribute اصلی:

Secure، HttpOnly و SameSite

هرکدام نقش متفاوتی دارند.

Secure مانع ارسال Cookie روی Connectionهای HTTP معمولی می‌شود.

HttpOnly خواندن مستقیم Cookie توسط JavaScript را محدود می‌کند.

SameSite رفتار ارسال Cookie در Contextهای Cross-Site را کنترل می‌کند.

اما هیچ‌کدام به‌تنهایی کافی نیستند.

یک معماری امن باید موارد زیر را نیز در نظر بگیرد:

HTTPS سراسری، Domain محدود، Path مناسب، Session Lifetime منطقی، Session Rotation، Server-Side Revocation، XSS Prevention، CSRF Protection، Reauthentication و Monitoring.

برای بسیاری از Session Cookieهای معمول، Baseline مفهومی زیر می‌تواند نقطه شروع خوبی باشد:

Secure + HttpOnly + SameSite=Lax/Strict

و در صورت سازگاری معماری:

__Host-

نیز می‌تواند لایه امنیتی دیگری اضافه کند.

از طرف دیگر نباید Policyهای Cookie را بدون تست کورکورانه سخت‌گیرانه کرد.

Payment Gateway، OAuth، SSO، iframe و سرویس‌های Cross-Site ممکن است رفتارهای خاصی نیاز داشته باشند.

بنابراین راهکار حرفه‌ای این است:

Cookieها را Inventory کنید، حساسیت هرکدام را مشخص کنید، Scope آن‌ها را تا حد ممکن محدود کنید و تنظیمات Secure، HttpOnly و SameSite را بر اساس کاربرد واقعی اعمال کنید.

در WordPress نیز Cookie Authentication بخشی اساسی از Login است؛ بنابراین HTTPS، Session Lifetime، امنیت Pluginها، جلوگیری از XSS و مدیریت حساب Administrator مستقیماً با امنیت Cookie مرتبط هستند.