Want to learn more?
Learn about browser cookies, security attributes, and privacy implications for web applications.
Read the guideHow to Extract Cookies from Your Browser
To analyze your website's cookies, you need to extract them from your browser's Developer Tools. Here's how to do it in each major browser:
Google Chrome
-
Right-click anywhere on the page and select Inspect (or press
Ctrl+Shift+I/Cmd+Option+I) -
Click the Application tab at the top of DevTools
-
In the left sidebar under Storage, expand Cookies
-
Click on your domain to see all cookies
-
Right-click a cookie and select Copy to copy its value, or view the full cookie string in the Network tab under request headers
Pro Tip: In the Network tab, click any request, then look at the Cookie header under Request Headers to see the full cookie string format.
Mozilla Firefox
-
Right-click and select Inspect (or press
F12) -
Click the Storage tab at the top
-
Expand Cookies in the left sidebar
-
Click your domain to view all cookies with their attributes
-
Double-click any field to copy its value
Note: Firefox's Enhanced Tracking Protection may block some third-party cookies by default.
Microsoft Edge
-
Press
F12orCtrl+Shift+Ito open DevTools -
Navigate to the Application tab
-
Under Storage, expand Cookies
-
Select your domain to view cookies
-
Double-click fields to edit, or use the filter box to search
Safari (macOS)
-
First enable the Develop menu: Safari → Settings → Advanced → Show Develop menu
-
Press
Cmd+Option+Ito open Web Inspector -
Click the Storage tab
-
Select Cookies in the sidebar
-
View all cookies for the current page
Getting the Full Cookie String for Analysis
To analyze cookies with this tool, you need the full cookie string including all attributes. Here's how to get it:
Method 1: From Set-Cookie Response Headers
-
Open DevTools and go to the Network tab
-
Refresh the page to capture requests
-
Click on any request (especially the initial page load)
-
Look at Response Headers for
Set-Cookieheaders -
Copy the full header value including all attributes
Set-Cookie: sessionid=abc123; Secure; HttpOnly; Path=/; SameSite=Lax; Max-Age=3600
Method 2: From JavaScript Console
Note: This only shows cookies without HttpOnly flag (JavaScript-accessible cookies):
document.cookie
This returns cookies in the format: name1=value1; name2=value2
Cookie Security Best Practices
Properly configured cookies are essential for web application security and user privacy.
Security Flags
-
• Secure: Only send over HTTPS connections, protecting against man-in-the-middle attacks
-
• HttpOnly: Block JavaScript access, preventing XSS-based session theft
-
• SameSite: Control cross-site requests to prevent CSRF attacks
-
• Domain: Limit cookie scope to specific domains
-
• Path: Restrict to specific URL paths
Privacy Considerations
-
• Use minimal necessary data in cookie values
-
• Set appropriate expiration times (shorter is better)
-
• Comply with GDPR/CCPA requirements
-
• Provide clear cookie policies and consent
-
• Allow users to opt out of tracking cookies
Understanding SameSite Attribute Values
Value Behavior Use Case
Strict Cookie only sent in first-party context. Never sent with cross-site requests. Banking, admin panels, high-security applications
Lax Cookie sent with top-level navigations and GET requests from external sites. Most web applications (recommended default)
None Cookie sent with all requests. Requires Secure flag. Embedded content, third-party integrations
Common Cookie Vulnerabilities
Missing HttpOnly Flag
Session cookies without HttpOnly can be stolen via XSS attacks. Always set HttpOnly on authentication cookies.
Missing Secure Flag
Cookies without Secure flag can be intercepted on unencrypted connections. Always use Secure on HTTPS sites.
SameSite=None Without Secure
Modern browsers reject SameSite=None cookies without the Secure flag. Always pair them together.
Excessive Cookie Lifetime
Long-lived session cookies increase the window for session hijacking. Use appropriate expiration times.
Learn More About Cookie Security
Fixing Insecure Cookies
Step-by-step remediation guide with framework-specific examples
Cookie Prefixes Explained
Learn about __Secure- and __Host- prefixes for extra protection
Extracting Cookies for Analysis
Complete guide to viewing and exporting browser cookies
Security Assessment Services
Professional web application security auditing
GDPR/CCPA Compliance Concerns?
Tracking cookies without consent can lead to fines. We audit and remediate cookie compliance issues.
What Is Cookie Analysis
Cookie analysis examines HTTP cookies set by websites to understand data collection practices, security configurations, and privacy compliance. Cookies are small text files stored in browsers that track sessions, preferences, authentication state, and user behavior. Analyzing them reveals what data a website collects, how long it persists, and whether proper security flags are set.
With privacy regulations like GDPR, CCPA, and ePrivacy Directive requiring informed consent for non-essential cookies, understanding cookie behavior is a compliance necessity. Security teams also analyze cookies to ensure session tokens are protected against theft through XSS (Cross-Site Scripting) and CSRF (Cross-Site Request Forgery) attacks. A cookie analyzer provides a systematic view of all cookies, their attributes, and potential issues.
How HTTP Cookies Work
Cookies are set by servers using the Set-Cookie HTTP response header and sent back by browsers with every subsequent request. Key attributes control cookie behavior and security:
| Attribute | Purpose | Security Impact |
|---|---|---|
| Name=Value | The cookie data | Contains session IDs, preferences, tracking IDs |
| Domain | Which domains receive the cookie | Overly broad domains expose cookies to subdomains |
| Path | URL path scope | / sends cookie with all requests |
| Expires/Max-Age | When the cookie is deleted | Session vs. persistent cookie |
| Secure | Only sent over HTTPS | Prevents interception on HTTP connections |
| HttpOnly | Not accessible via JavaScript | Prevents XSS-based cookie theft |
| SameSite | Cross-site request policy | Strict, Lax, or None; mitigates CSRF |
| Partitioned | CHIPS (third-party partitioning) | Limits cross-site tracking |
Cookie categories for privacy compliance:
- Strictly necessary: Authentication, shopping cart, security (no consent required)
- Functional: Language preference, user settings (consent recommended)
- Analytics: Usage tracking, A/B testing (consent required)
- Marketing: Cross-site tracking, retargeting (consent required)
Common Use Cases
- Privacy compliance auditing: Identify all cookies and classify them by purpose for GDPR/CCPA consent management
- Security assessment: Verify that session cookies have Secure, HttpOnly, and SameSite flags set correctly
- Third-party tracking discovery: Find cookies set by advertising, analytics, and social media scripts
- Incident investigation: Analyze suspicious cookies that may indicate session hijacking or unauthorized tracking
- Vendor due diligence: Evaluate what cookies third-party scripts inject into your users' browsers
Best Practices
- Set Secure, HttpOnly, and SameSite on all sensitive cookies — Session tokens must have all three flags to prevent theft and CSRF
- Use SameSite=Strict or Lax — The None value requires the Secure flag and allows cross-site requests, which is rarely needed
- Minimize cookie lifetime — Session cookies (no Expires) are deleted when the browser closes; persistent cookies should have the shortest practical lifetime
- Audit third-party cookies regularly — Third-party scripts frequently add new cookies without notification; scan monthly
- Implement a cookie consent mechanism — GDPR requires opt-in consent for non-essential cookies; block analytics and marketing cookies until consent is given
References & Citations
- Internet Engineering Task Force (IETF). (2011). HTTP State Management Mechanism - RFC 6265. Retrieved from https://datatracker.ietf.org/doc/html/rfc6265 (accessed January 2025)
- Mozilla Developer Network. (2024). Using HTTP cookies. Retrieved from https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies (accessed January 2025)
- web.dev. (2023). SameSite cookies explained. Retrieved from https://web.dev/samesite-cookies-explained/ (accessed January 2025)
Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.
Key Security Terms
Understand the essential concepts behind this tool
Frequently Asked Questions
Common questions about the Cookie Analyzer
What are HTTP cookies?
HTTP cookies are small data pieces stored by browsers, sent with every request to same domain.
Used for: session management (login state), personalization (preferences), tracking (analytics, ads).
Set via Set-Cookie header or JavaScript document.cookie.
Contains: name, value, expiration, domain, path, security flags.
Types: session cookies (temporary), persistent cookies (long-lived), first-party (same domain), third-party (different domain).
GDPR requires consent for non-essential cookies.
What is the HttpOnly flag?
HttpOnly flag prevents JavaScript access to cookies via document.cookie.
Mitigates XSS attacks - stolen session cookies via script injection.
Example: Set-Cookie: sessionid=abc123; HttpOnly.
Cookie still sent in HTTP requests but hidden from client-side scripts.
Essential for authentication cookies.
Not bulletproof - XSS can still make authenticated requests (CSRF).
Use with: Secure flag, SameSite, CSP.
Check: browser DevTools Application tab shows HttpOnly column.
What is the Secure flag?
Secure flag ensures cookies only transmitted over HTTPS, never unencrypted HTTP.
Prevents eavesdropping on unsecured networks.
Example: Set-Cookie: token=xyz789; Secure.
Required for sensitive data (sessions, auth tokens, personal info).
Modern browsers require Secure for SameSite=None cookies.
Local development: use localhost (exempt) or HTTPS proxy.
All production cookies should use Secure flag.
HTTP sites cannot set Secure cookies.
What is SameSite attribute?
SameSite prevents CSRF attacks by controlling when cookies sent in cross-site requests.
Three values:
- Strict (never sent cross-site, safest)
- Lax (sent on top-level navigation GET, default)
- None (always sent, requires Secure flag).
Example: Set-Cookie: id=123; SameSite=Strict.
Use Strict for sensitive actions (banking), Lax for general sites, None for third-party integrations (OAuth, payment).
Modern browsers default to Lax if omitted.
How to set cookie expiration?
Two attributes: Expires (specific date) or Max-Age (seconds from now).
Example: Expires=Wed, 21 Oct 2025 07:28:00 GMT or Max-Age=3600 (1 hour).
Session cookies: omit both attributes, deleted when browser closes.
Persistent cookies: set expiration.
Security: short-lived tokens (minutes-hours), long-lived remember-me (days-weeks).
Auto-renewal: refresh token before expiry.
Privacy: GDPR limits persistent cookie duration.
Use Max-Age (easier calculation).
First-party cookies:
set by visited domain (example.com on example.com).
Used for: sessions, preferences, analytics.
Third-party cookies:
set by different domain (ads.tracker.com on example.com).
Used for: cross-site tracking, retargeting, analytics.
Browser trends:
Safari/Firefox block third-party by default, Chrome phasing out 2024-2025.
Alternatives:
first-party data collection, server-side tracking, Privacy Sandbox.
GDPR:
requires explicit consent for non-essential cookies (both types).
Best practices:
HttpOnly flag (prevent XSS theft).
Secure flag (HTTPS only).
SameSite=Strict or Lax (prevent CSRF).
Short expiration (15-60 min).
Prefix: __Host- or __Secure- (enforces Secure + domain restrictions).
Cryptographic signing (HMAC-SHA256).
Regenerate session ID after login.
Clear cookies on logout.
Example:
Set-Cookie: __Host-sessionid=abc; Secure; HttpOnly; SameSite=Strict; Max-Age=3600.
What are cookie prefixes?
Cookie prefixes enforce security requirements:
__Secure- prefix requires Secure flag and HTTPS.
__Host- prefix requires: Secure flag, no Domain attribute (exact domain only), Path=/.
Example: __Host-token=xyz forces most restrictive settings.
Prevents: subdomain/related-domain cookie injection, downgrade attacks.
Browser enforces requirements - invalid combinations rejected.
Use __Host- for maximum security (auth tokens), __Secure- for general secure cookies.
Not widely adopted yet but recommended.
First-party cookies are set by the website you visit and are used for essential functions like login sessions. Third-party cookies are set by external domains (like ad networks) and track users across websites. Browsers are increasingly blocking third-party cookies for privacy.