Security

A calendar app wants to read your Google Calendar. It should never see your Google password, not even once to throw it away. OAuth 2.0 is the protocol that makes that possible: your Google account issues the calendar app a token that lets it read your calendar and nothing else, and the app never touches your credentials. That’s delegated authorization, and it’s a different problem from authentication. JWT vs session authentication covers how a server decides who you are. OAuth answers a narrower question: can this other application act on your behalf, and for what. Most OAuth mistakes start when people mix the two up. ...

Log a user out of a session-based app and the server forgets them on the next request. Log them out of a JWT-based app and, unless you built extra machinery for it, the token they’re holding stays valid until it expires. That difference is the real decision behind “JWT vs session”. The rest follows from it. What a session actually stores A session keeps the user’s state on the server and hands the browser only a lookup key. ...

A login endpoint hands back a JWT, and you have three places to put it: a cookie, localStorage, or sessionStorage. Pick the wrong one and either an XSS bug walks off with the token, or the token never reaches your API. All three store strings in the browser. They differ on who can read them, how long they last, and whether the server ever sees them. How localStorage, sessionStorage and cookies differ localStorage and sessionStorage are the same API, the Storage interface: setItem, getItem, removeItem, clear, string keys and string values. The difference is lifetime. localStorage survives closing the browser and rebooting the machine, and stays until something clears it. Safari is the exception: with tracking prevention on, it deletes script-written storage for a site the user hasn’t interacted with in seven days. sessionStorage belongs to one tab and dies when that tab closes. Type the same URL into a second tab and you get a fresh, empty sessionStorage; only “Duplicate tab” copies it over. ...

Your frontend runs on http://localhost:5173, your API on http://localhost:4000, and the fetch call that worked fine in Postman fails in the browser with a wall of red text: Access to fetch at 'http://localhost:4000/api/users' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Your server may well have handled that request and returned a 200. The browser refused to hand the response to your JavaScript. ...

How do you reach a database that only listens on localhost? A Postgres instance on a remote server binds to 127.0.0.1 on purpose. Nothing on the network can reach it, only processes running on that same box. Your laptop is not that box, so psql -h remote-server -p 5432 fails before it gets anywhere near authentication. Opening the port to the world defeats the reason it was bound to loopback in the first place. ...

What TLS actually protects on an HTTPS connection Load a page over plain http:// on a network you don’t control, an airport or a coffee-shop router, and everything you send travels as readable text. The URL path, the cookies, the form fields, the password in a login POST: anyone on that network with a packet sniffer reads it as it goes past. TLS, Transport Layer Security, is the protocol that stops that. It sits between TCP and the application protocol, so by the time HTTP starts talking, the connection is already encrypted and tied to a verified server identity. HTTPS is HTTP run over that connection instead of a plain one. ...

Where a container’s environment variables end up Start a container with -e DB_PASSWORD=hunter2 and run docker inspect on it: 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] The password sits there in plain text, readable by anyone with access to the Docker socket, by docker exec api env, and by any process running inside the container. That is not a bug — it is what environment variables are for. The problem is using them for values that should never be that visible. ...