When threat-modeling a web app, why is the browser drawn as an external entity outside your trust boundary?

## What a trust boundary is actually grouping A data-flow diagram used for threat modeling is not a deployment picture. It groups elements by **who runs them and under whose authority they execute**. A trust boundary is the line where that answer changes, and its whole purpose is to mark the crossings where data or a request moves from one level of trust to another - because those crossings are where you have to do work. A browser is the cleanest example available. You wrote the page it loaded; you do not run the thing that executes it. It sits on a laptop you have never seen, under an operating system you do not patch, next to extensions you did not install, and its developer tools are one keypress away. That is the entire argument: **placement follows control, not code authorship**. The JavaScript is yours, the execution is not. ## What follows mechanically Once the browser is outside, everything on the inbound flow is a *claim*, not a fact: - Form fields, including hidden ones and ones a `disabled` attribute greyed out. - Headers, and any value a page put in one. - Which endpoint is called, in which order, and how fast. - Whether the request came from your page at all - the same HTTP request can be produced by a script that never rendered your UI. So the model must treat every inbound flow as untrusted input and ask, per crossing: what is validated here, and where is the authority for this decision. On a parking-fine site, the anonymous payment flow posts a fine reference and an amount. The amount is not data the server may use; it is a suggestion. The server looks up the fine and computes the fee itself. If the model records 'the page only offers the correct amount' as the mitigation, the threat is live and the risk rating is a fiction. The asset here is money, and the attacker is an anonymous member of the public - no account, no privileges, nothing to compromise first. ## The invented-mitigation failure The most common defect in a first web-app model is not a missed threat; it is a **credited control that runs on the attacker's side of the line**. It looks like this: | Claimed mitigation | Where it runs | What it is worth | | --- | --- | --- | | Client-side field validation | Browser | Usability. Zero. | | Disabled or hidden submit button | Browser | Usability. Zero. | | Hidden form field carrying a price or role | Browser | Worse than zero - it advertises the parameter. | | A multi-step wizard that enforces order | Browser | Zero; steps can be called directly. | | Server recomputes the value from its own records | Server | The actual control. | Keep the client-side checks - they give instant feedback and cut junk traffic - but record them in the model as user experience. The defect is not having them; it is listing one as the answer to a tampering threat and then rating that threat down. ## TLS does not move the line A second recurring mistake is treating HTTPS as though it made the browser trusted. Transport security protects a flow **in transit** against a third party: it gives confidentiality and integrity between the two endpoints, plus server authentication. It says nothing about whether the endpoint at the other end is honest, and it certainly does not stop the person operating that endpoint from editing what they send. An attacker's own requests are encrypted too. On the diagram, TLS annotates the flow; it does not move the boundary. ## Which threat categories attach here In STRIDE-per-element analysis, element type determines which of the six categories are worth enumerating: - **External entity** (the browser, the user behind it): **spoofing** - is this identity what it claims to be - and **repudiation** - can this party later deny having acted. - **Data flow** (the request and response crossing the boundary): **tampering**, **information disclosure**, **denial of service**. - **Process** (your request handler): all six. - **Data store**: tampering, information disclosure, denial of service, plus repudiation where the store is the log that has to prove what happened. Each category names a violated property: spoofing violates authentication, tampering violates integrity, repudiation violates non-repudiation, information disclosure violates confidentiality, denial of service violates availability, elevation of privilege violates authorization. Naming the property is what turns a category into a testable requirement. ## How to draw it Put the browser at the left as an external entity, draw one boundary around what you run - the handler process and its stores - and let every request and response cross that single line. Resist drawing the boundary around 'the internet': a boundary that separates nothing you can act on tells you nothing. The value of the line is that it forces the next question for each crossing, which is what the rest of the model is built on: what does this handler verify about this request before it acts on it, and does that verification live on my side of the line.