secure-coding

I teach SQL injection by showing the vulnerable pattern first and then replacing it with parameterized queries. The important point is that escaping is not a strategy and string interpolation is not acceptable anywhere user input reaches SQL. I also p

I validate input at trust boundaries, not halfway through business logic. Explicit schemas force decisions about allowed types, lengths, enums, and nested structure. That keeps weird payloads from becoming security bugs and makes error behavior much e

Predictable tokens become account compromise. I use cryptographically secure randomness, store only token digests when possible, and keep token purpose and expiry specific. Reset tokens, magic links, and API secrets should all be treated like credenti

Even outside ORMs, parameterized database access needs to be the default habit. The query string should describe structure while the driver binds user values separately. That sounds basic, but it is still where too many internal tools quietly fail sec

XML is still a problem when parsers are left in permissive mode. I disable external entities, refuse network fetches, and prefer simpler formats unless XML is required by an external integration. Attackers love parser defaults that nobody revisited af

Any endpoint that reads from disk needs path normalization and strict base-directory enforcement. I never trust user-supplied file names and I avoid passing them straight into shell commands. Safe file access is mostly about refusing to be clever.

File uploads are attacker-controlled input with extra surface area. I validate extension and MIME type, rename everything server side, scan risky formats, and keep user uploads out of executable paths. If the business allows arbitrary uploads, storage

SSRF defense requires more than banning localhost. I parse URLs with a real library, enforce scheme and host allowlists, resolve and reject private IP ranges, and pair app-level checks with network egress rules. If an attacker can turn your server int