Web Security & Threat Modeling — Node.js Course

What you'll learn

Security starts with a model of what can go wrong. Map assets, actors, data flows, and trust boundaries, then rank abuse cases and attach controls that can be tested and observed.

By the end of this lesson, you'll be able to:

Map assets and trust boundaries
Write concrete abuse cases
Prioritize risk by impact and likelihood
Connect mitigations to verification

Core mental model

Node.js becomes easier when you separate the JavaScript language from the runtime and the operating-system capabilities it exposes. Use this table as a decision guide.

Concept	What it means	Decision rule
Asset	Something valuable to protect	Include identities, tenant data, secrets, availability, and audit evidence
Trust boundary	A point where assumptions or authority change	Validate and authorize every crossing
Abuse case	An attacker-oriented scenario	Describe actor, action, impact, control, and evidence

Professional workflow

Build and verify Node.js programs from the terminal in small, observable steps.

Define the threat model boundary: inputs, outputs, invariants, ownership, and expected failures.
Design the data or message contract before choosing implementation details.
Implement the smallest correct path with dependencies passed explicitly.
Add validation, failure translation, cleanup, and concurrency behavior.
Verify the boundary with realistic data and at least one adversarial case.
Measure or observe the behavior before optimizing or extracting abstractions.

Keep the feedback loop short

Run the smallest useful command after every meaningful change. Read the complete error message before editing again, and keep inputs and outputs visible while you learn.

Guided code lab

Turn a feature into a threat record

A compact record makes ownership and verification explicit before implementation.

threat-model.js

const threat = {
  asset: 'tenant task data',
  boundary: 'HTTP request -> task service',
  abuse: 'user reads another tenant by changing taskId',
  controls: ['authenticated subject', 'tenant-scoped repository query'],
  verification: ['cross-tenant integration test', 'denial audit event'],
  residualRisk: 'incorrect admin policy',
};

Production practice

Contract

Every sensitive flow names its actor, asset, trust boundary, authorization rule, failure response, and audit evidence.

Verification

Add negative tests for horizontal and vertical privilege escalation, malformed input, replay, resource exhaustion, and secret exposure.

Operations

Assign risk owners, review models when data flows change, and connect detections to an incident runbook.

Common failure mode

A checklist without system context can add controls while missing the highest-impact path. Model the actual data flow first.

Independent workshop

Threat-model the multi-user task API before adding authentication.

Your finished workshop must include:

Data-flow diagram
Asset inventory
Four trust boundaries
Eight abuse cases
Risk ranking
Mitigation/test mapping

Definition of done

Run the happy path and at least two edge cases, keep responsibilities separated, and add a short README explaining how to run the program.

Recap & quick check

Key takeaways

Security is risk management
Boundaries require verification
Least privilege limits blast radius
Controls need tests
Residual risk stays visible

Quick check

1. What is the best starting point?

2. What makes a mitigation actionable?

3. What does least privilege reduce?

Next: Password Authentication & Sessions