Authentication, access rules, secrets and rate limiting, including the ones we got wrong in our own code.

Authentication is working out who someone is. Authorisation is deciding what they are allowed to do once you know. A login is authentication. Refusing to show one client another client's invoice is authorisation. They fail differently, and the second is where most real breaches happen.

A session is the app remembering you between requests. After you log in, the server hands your browser a signed cookie or token, and your browser sends it back with every request. HTTP itself has no memory, so without that token every page load would be a stranger arriving.

Access rules are permissions enforced by the database itself rather than by your application code. Firestore and Cloud Storage call them security rules; Postgres calls it row-level security. They decide whether a given user may read or write a given record, and they run even when your app does not.

Least privilege means every account, service and key gets the narrowest access that lets it do its job, and nothing spare. Not because you distrust anyone, but because the damage from a mistake or a stolen credential is bounded by what that credential could reach.

In a secret manager or your host's encrypted environment settings, never in the repository. Google Secret Manager, AWS Secrets Manager and Vault all do this. The rule is simple: if a secret is in git, treat it as public, because git history keeps it after you delete the file.

Security headers are instructions a server sends with every response telling the browser what to allow. The ones that earn their place are Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options and Referrer-Policy. They cost nothing to send and remove whole classes of attack.

Rate limiting caps how many requests something may make in a window: 10 login attempts a minute, 100 API calls an hour. It protects against brute force, scraping and runaway costs. What it protects against depends entirely on what you key it to, and that is where most implementations go wrong.