Security Mindset

Two Ways to Read a Product

Builders and attackers look at the same product with different questions.

A builder asks, does this work? You test the happy path: valid input, a logged-in user, the expected clicks.

An attacker asks, how can I make this do something it was never meant to do? They test the edges you skipped.

That gap in questions is why attackers spot flaws builders miss. A security mindset means asking both.

Every Feature Hides Assumptions

Every feature rests on assumptions you rarely write down.

You assume the client sends the order ID of the logged-in user. You assume the price comes from your catalog. You assume uploads are images.

Attackers treat each assumption as a question to test. If they change the ID in the URL, does your API still return the order?

Listing your assumptions is the first step to thinking like an attacker.

Know Your Trust Boundaries

A trust boundary is any point where data moves from a less trusted place to a more trusted one.

Think in zones: the public internet, signed-in users, your internal services, and the database at the core.

The browser sits outside. Anything it sends, including hidden fields, headers, and JavaScript checks, can be edited by the user.

So client-side validation is for user experience. The server must validate again every time data crosses inward.

Write Abuse Cases

Product teams write user stories. Security-minded teams also write abuse cases.

Take a story like: As a user, I can reset my password by email. Now flip the actor: As an attacker, I can reset someone else's password.

Then ask how. Guessable reset tokens? Links that never expire? No rate limit on requests?

Each answer becomes an acceptance criterion before any code ships.

Make It a Routine

Threat modeling turns the mindset into a routine. A common version uses four questions.

What are we building? What can go wrong? What will we do about it? Did we do a good job?

The last question feeds the next round. New features, new integrations, and new data all reopen the loop.

Run it at design time, when a fix is a whiteboard edit instead of a rewrite.

The Defender's Dilemma

Here is the uncomfortable math of security.

Defenders must protect every path. An attacker needs to find only one that works.

That is why security added at the end rarely holds. A late audit finds some holes, but design flaws are already baked into the architecture.

The mindset moves the work earlier, so fewer weak paths exist to begin with.

Using It on Your Team

You do not need a security title to think like an attacker.

In design reviews, list assumptions and mark trust boundaries.

In planning, pair each key user story with an abuse case and turn the answers into acceptance criteria.

In code review, ask: what happens if this input is missing, huge, or hostile?

Small habits like these catch flaws before attackers do.

A test confirming that a logged-in user can check out with valid input reflects the _____ question

• builder's
• attacker's

Answer: builder's

This is the happy path: valid input, a logged-in user, expected clicks. It answers the builder's question, does this work? An attacker would instead ask how to make checkout do something it was never meant to do, such as changing the price or another user's order.

A _____ describes what a legitimate user can do. An _____ flips the actor to an attacker. Each answer to 'how could they do it?' becomes an _____ before code ships.

Answer: A user story describes what a legitimate user can do. An abuse case flips the actor to an attacker. Each answer to 'how could they do it?' becomes an acceptance criterion before code ships.

Example: 'As a user, I can reset my password by email' becomes 'As an attacker, I can reset someone else's password.' Asking how (guessable tokens, links that never expire, no rate limit) yields concrete acceptance criteria that must be met before release.

An API returns any order whose ID appears in the URL. An attacker swaps in a different ID. Which unwritten assumption are they testing?

• The client sends only the logged-in user's own order ID
• The order's price always comes from the product catalog
• Uploaded files attached to orders are always images
• The database responds quickly under heavy load

Answer: The client sends only the logged-in user's own order ID

Every feature rests on unstated assumptions. Here the builder assumed the client would only send the logged-in user's own order ID. Attackers treat each assumption as a question to test; if the API returns someone else's order, the assumption failed. Listing assumptions is the first step to thinking like an attacker.