Your web app's admin console shares a hostname and session with the public site - how do you model it?

## One deployment, two surfaces A surface in a threat model is defined by **who can reach it and what it can do**, not by DNS. A university course-registration portal that serves students, faculty and a registrar back-office console from one server-rendered app on one hostname has at least two surfaces, because the population that can reach the registrar functions and the damage those functions can do are both different from the public ones. Collapsing them because the deployment is single gives you one blended threat list and one blended risk rating that describes neither. ## Where the boundary line goes The useful move is to draw a boundary **inside the process**. On the diagram it encloses the handlers that act with elevated rights, and the crossing is the exact point in the request lifecycle where a decision is made that this session may act as a registrar. That is a real boundary even though no network, container or hostname separates the two sides, because a boundary on a diagram is a claim that *something checks here*. If you cannot name the check, you have drawn a wish rather than a boundary - which is itself a useful finding to surface in a review. Drawing it forces the enumeration to be specific. Against that one crossing: - **Reaching a privileged route directly.** The link is not in a student's navigation, but navigation is rendering, not authorization. The request can be issued regardless. - **A role fact sourced from the wrong side.** Anything the client can influence - a parameter, a field the page round-trips, a value chosen by the client and echoed back - cannot be the input to the decision. The authority has to be server-side state or a server-verified assertion. - **A shared handler that branches.** One endpoint serving both audiences and deciding by request content is the classic place the check gets skipped on one path. - **A second-step gap.** The entry screen checks the role; the action that follows assumes the entry screen was passed. Each privileged action needs its own decision, because each is separately reachable. - **Read versus write asymmetry.** Listing views often get a weaker check than the mutating action next to them, and the listing is frequently where the sensitive record is exposed. ## Why elevation dominates, and what comes second STRIDE gives six categories, each violating one 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. On a privileged path inside an application the crossing you have just drawn is an **authorization** crossing, so elevation of privilege is what the diagram is asking about. It is worth being precise here: an authenticated student reaching a registrar function is not spoofing - the identity is genuine and correctly established. What went wrong is the rights attached to it. Repudiation comes second and is often underweighted. The asset behind a registrar console is not only the data but **the credibility of the record**. A grade change or a back-dated add/drop has value precisely because the institution can assert it happened, by whom and when. So the model should record an explicit requirement: every privileged action produces an attributable, tamper-evident entry naming the acting account, the target record, the before and after, and the time. Without it, the same defect produces an incident nobody can reconstruct. Information disclosure is real but usually downstream: it is what an attacker gets *after* crossing, which is why the crossing itself is the thing to rate. ## Modeling the right attacker The habitual failure is to model only the anonymous outsider. On this shape the interesting attacker is an **authenticated low-privilege user**: someone with a legitimate account, real credentials, unlimited patience and a genuine session. They can read every page the application serves to them, observe parameter names, and try any route. Writing that attacker down at the top of the model changes what gets enumerated, because a threat that starts from 'the user is already logged in' is not exotic - it is Tuesday. ## Does splitting the deployment fix it Moving the console to another hostname, another service, or behind an internal network is genuinely useful: it shrinks the population that can reach the routes at all and adds a prerequisite an outsider must satisfy first. It changes the **attacker set**, not the authorization decision. If the handler still grants rights on a wrong basis, the same request works from a position inside. Model network placement as exposure reduction and keep the authorization crossing where it is. ## Rating them apart Because the two surfaces have different attackers and different assets, rate them apart. A blended number - one score for 'the portal' - hides that the public flows are high-volume and low-value per event while the registrar flows are rare and high-consequence. Two rows, two attackers, two assets, two ratings. That is also what makes the model useful to whoever has one sprint and has to pick.