The security mindset and threat modelling

Most security bugs are not clever hacks. They are ordinary mistakes: a check that was forgotten, a secret left in a file, input that was trusted when it should not have been. Security is the habit of asking "how could this be misused?" while you build, not after you ship.

This lesson gives you the vocabulary, the mindset and a simple method called threat modelling that you can use on any app. We will use the Brew & Bean pickup-order app as the example. Everything in this track is defensive: you practise on your own apps and on labs built to be attacked.

Notice that risk is about likelihood times impact. A bug that is easy to exploit and exposes phone numbers matters more than a bug that needs rare conditions and exposes nothing important. You cannot fix everything first, so you rank.

Security goals are often grouped into three ideas. They are called the CIA triad (nothing to do with the agency).

Confidentiality: only the right people can read the data. Integrity: data cannot be changed in ways it should not be. Availability: the system works when people need it.

For Brew & Bean: a leaked phone number breaks confidentiality. A customer changing the price of their own order breaks integrity. A flood of fake orders that stops real customers from ordering breaks availability. When you review a feature, ask which of the three it could hurt.

The security mindset has a few habits.

Never trust input. Anything that comes from outside your server is untrusted: form fields, URL parameters, headers, cookies, uploaded files, even data from your own frontend. The browser is under the user's control, so a hidden field or a disabled button is a suggestion, not a rule.

Assume failure. Passwords will leak somewhere, one layer will be bypassed, a developer will make a mistake. Design so that one failure does not become a disaster. This is called defence in depth: several independent layers.

Least privilege. Give every user, service and key only the access it needs. The database account used by the website does not need permission to drop tables.

Keep it simple. Every feature, endpoint and dependency is more attack surface. Features you do not need are risk with no benefit.

Secure by default. The safe option should be what happens when nobody configures anything.

Threat modelling sounds formal, but the core is four questions you can ask on a whiteboard in 30 minutes. They come from well-known threat-modelling guidance such as OWASP's.

1. What are we building? 2. What can go wrong? 3. What are we going to do about it? 4. Did we do a good enough job?

STRIDE is a memory aid from Microsoft with six categories of threat. Walk through each one for each part of your diagram.

Take one feature: a customer places an order with POST /orders. The request travels from the customer's phone browser, over the internet, to the FastAPI server, which writes to the database. The trust boundary is between the browser and the API.

Walking through STRIDE gives a short table of findings.

Four of these five have the same root cause: trusting what the client says. The fixes are covered in this track: *Authorisation and broken access control*, *Injection attacks* and *Securing APIs*.

Do a short threat model when you design a feature, change how data flows, add a third-party service or handle new sensitive data. Do it again when the design changes. Small and frequent beats big and rare.

Threat modelling is also the cheapest security work. Fixing a design problem on a whiteboard costs minutes. Fixing it after launch can cost weeks and your users' trust.

Act as a security reviewer helping me threat model a feature. Use the STRIDE categories.

Feature: [describe the feature, e.g. customers log in and view their past orders].
Tech: [e.g. React frontend, FastAPI backend, Postgres, hosted on Render].
Data handled: [e.g. name, phone, order history].

For each STRIDE category give up to two realistic threats, how likely and how serious each is (low/medium/high), and one concrete defensive control. Output a table. Only defensive advice, no exploit instructions.

What to expect: Check each threat against your real design. AI will list generic threats, so delete the ones that do not apply and add ones it missed. Treat the output as a prompt for discussion, not a finished model.

Interviewers rarely ask you to recite STRIDE. They ask "how would you secure this feature?" or "what could go wrong with a login page?" A strong answer names the assets, walks through who could attack and how, and gives layered controls. Saying "I would first ask what we are protecting and from whom" signals maturity. Also be ready for: the CIA triad, defence in depth, least privilege, and the difference between authentication (who are you) and authorisation (what may you do).