Thinking like an attacker

Security isn't a feature you add at the end; it's a mindset you bring throughout. Authentication and access control are only as strong as the attacker's ability to find gaps in them. Where a normal user asks "how do I use this?", an attacker asks "how do I abuse this?" Threat modeling is the discipline of asking that second question deliberately, before someone else does it for you.

Assume hostile input

The foundational rule: never trust input. Anything from outside your program — form fields, URLs, uploaded files, API requests, even data from another service — may be crafted to break you. The first lesson's point about machines doing exactly what you said cuts both ways: an attacker will say something malicious and your code will obey unless you validate.

Validate and sanitise at every boundary (the systems-thinking edges). "It'll never be that long / that shape / negative" is exactly the assumption attackers exploit.

A basic threat model

You don't need to be a security expert to model threats. Walk through four questions:

1. What are we protecting? (User data, money, availability, credentials.)
2. Who might attack, and why? (Opportunists, insiders, automated bots.)
3. How could they get in? (Every input, every trust boundary, every dependency — including injection via untrusted data.)
4. What will we do about each? (Validate, authenticate, limit, monitor.)

Doing this on a whiteboard while designing catches whole classes of problems for the price of a conversation.

Two principles that do a lot of work

• Defense in depth: don't rely on a single safeguard. Layer them, so one failure isn't a breach. (Validation and authorization and monitoring.)
• Least privilege: give every user, service, and credential the minimum access it needs, nothing more. A compromised component with little power does little damage.

Where to go next

The most common trust boundary is "who are you, and what may you do?" Next: authentication and authorization.