Going to quote these lines in any #tradeoff discussions going forward:

Would you like the strongest encryption algo in world? Yes.
Would you like logins to take ten minutes? No.
- @stevekinney in @FrontendMasters course on web security
— Ankit Kashyap (@ankitwww) February 8, 2025

the most secured systems are the ones people don’t want to use.

In security world, perfect is many times opposite of good.

Cookies

small pieces of data stored on the client side to track and identify users
Cookies are used to implement sessions.
You don’t need to be logged in.
Cookies are not always tied to authentication and authorization.
Without some kind of expiration, cookie last for the duration of the session.
For expiration - two options - Expires or Max age
How to delete the cookie
- You can’t
- But, you can set its expiration date to some time in the past.
httpOnly
- JS can’t change cookie httpOnly
- Sometimes you want js to still read/edit the cookie (e.g. dark mode?)
- Setting the HttpOnly flag on a cookie enhances security by making it inaccessible to JavaScript running in the browser. This helps protect against cross-site scripting (XSS) attacks, where a malicious script could otherwise steal sensitive cookies (e.g., session tokens) and send them to an attacker.
  - XSS attacks inject scripts into web pages that run in the user’s browser.
  - If session cookies are accessible through document.cookie, attackers can steal them and hijack user sessions.
  - HttpOnly prevents this by restricting cookies to be sent only in HTTP(S) requests.
- HttpOnly does not protect against Cross-Site Request Forgery (CSRF) attacks. To mitigate CSRF, combine HttpOnly with CSRF tokens or set SameSite=Strict or SameSite=Lax.
- HttpOnly does not encrypt cookies; always use Secure to ensure cookies are sent only over HTTPS.
Secure
- The Secure flag in a cookie ensures that the cookie is only sent over HTTPS and never transmitted over an unencrypted HTTP connection. This prevents attackers from intercepting and stealing the cookie through man-in-the-middle (MITM) attacks.
Signing/hashing the cookie
- Signing a cookie means adding a cryptographic signature to its value to ensure integrity and authenticity. This prevents attackers from tampering with or forging the cookie’s content while still allowing the server to read it.
Signing vs Encrypting:
- encryption and signing are fundamentally different cryptographic operations, and they serve distinct purposes.
SameSite: Restricts how cookies are sent with cross-origin requests
But Site !== origin
- example.com and login.example.com are same site
- Exceptions: github.io and vercel.com sub domain
Same Origin Policy
- Protocol + Host + Port = origin
More on this in CSRF
The SameSite attribute in cookies controls whether cookies are sent with cross-site requests. It helps prevent Cross-Site Request Forgery (CSRF) attacks by restricting when a browser should send cookies.

Weired things

Session Hijacking

Privilege Escalation
Man-in-the-middle - HTTP
SQL Injection - Escape user inputs
Parameter Injections in URLs, non-sql DBs
- Use input validations
- Use allowLists instead of blockLists
- avoid ppl to slide properties/things like {…obj, admin: true} in PATCH apis

Cross-site request forgery

A vulnerability that allows an attacker to make unauthorized requests in the user’s behalf.

3 Ingredients to the CSRF

CSRF fixes

SameSite Cookie and CSRF

SameSite:Lax is default these days SameSite:None is irresponsible

SameSite=Strict:

Banks or critical sites can enforce it - but a social media won’t go for it.
- Otherwise, message forwards and links shared across other website won’t work smoothly and would show up login page again (degraded experience).
SameSite: Restricts how cookies are sent with cross-origin requests
Site !== origin
- example.com and login.example.com are same site
- origin - Protocol + hots + port
- Exceptions: github.io and vercel.com sub domain