Securing your web app

Most breaches are not exotic. They come from the same handful of gaps left open under deadline pressure. Cover the baseline below and you have already shut the doors attackers try first.

Authentication and sessions

• Hash passwords with a slow, salted algorithm — scrypt, bcrypt, or argon2. Never store plaintext, never roll your own.
• Use opaque, server-side sessions. Store a hash of a random token, not the token itself; set absolute and idle expiry; make logout actually revoke.
• Lock down cookies with HttpOnly, Secure, and SameSite so session cookies stay out of reach of JavaScript.

Trust no input

• Parameterize every query. String-built SQL is the oldest hole in the book.
• Validate on the server. Client-side checks are for UX; the server is the boundary that counts.
• Validate uploads by type and extension, cap the size, and store them outside the web root.

Lock down the edges

• Enforce authorization on every route, not just in the UI. A hidden button is not access control.
• Protect state-changing requests from CSRF with a token or a strict same-origin check.
• Set security headers — HSTS, a content security policy, sensible referrer and frame rules.

Keep it that way

Security is not a launch milestone, it is maintenance. Patch dependencies on a schedule, keep secrets in the environment and out of git, and log enough to notice when something is off. The dull habits are what hold up after the launch adrenaline wears off.