9 posts
Webhook security matters because a webhook is an instruction from outside your app. A payment provider says "this invoice was paid" and your code ships the order. A code host says "this branch was pushed" and your…
Threat modeling sounds like something a large company does with a security department and a binder. It is not. At its core it is a short, structured conversation about how your app could be misused and what you will do…
Session cookie security is easy to overlook because your framework sets the cookie for you. Users sign in, a cookie appears, and everything works. But that one cookie is the user's identity for as long as it lives, and a…
Security headers are short lines your server adds to every response, telling the browser how to treat your pages: only over HTTPS, not inside someone else's frame, without guessing file types. They are cheap to add and…
Password reset security deserves as much care as the login form, because the reset flow is a second way into every account. Anyone can start it with just an email address, and if the link, the token or the page behind it…
Login rate limiting is one of those controls every team means to add and few teams test. The login form works, the signup form works, and nobody tries the hundredth wrong password until someone outside the company does.…
Frontend secrets are API keys and passwords that end up in the JavaScript your visitors download. It happens to careful teams, because the key was "in an environment variable" and that felt private. But build tools copy…
File upload security is easy to underestimate. An avatar picker or an invoice upload looks like a small feature, but it lets anyone with an account put a file of their choosing on your servers. If the app trusts the…
Most security problems in a young web app are not exotic. They sit in the two places every product has to get right on day one: sign-in, where a mistake hands someone else's account to a stranger, and payments, where a…