Trust Boundaries

Trust boundaries — wherever data or control transitions from one trust level to another, that boundary requires explicit security enforcement. All vulnerabilities can be traced to insufficient validation at a trust boundary.

Trust levels in a typical web application:

Zone	Trust level	Required controls at boundary crossing
Internet / public	0 — fully untrusted	TLS, WAF, rate limiting, full input validation
Authenticated user session	1 — authenticated but untrusted for data content	Auth verification, session validation, input sanitisation
Internal application logic	2 — trusted for own processing	Parameterised queries, output encoding, service auth
Database layer	3 — high trust for stored data	DB user least privilege, encryption at rest, audit logging
External third-party API	1 — untrusted (even if "partner")	Response validation, schema enforcement, error handling

Why every vulnerability traces to a trust boundary:
• SQL injection: user input (trust level 1) crosses a trust boundary into SQL execution (trust level 3) without parameterisation
• XSS: user input crosses into the DOM execution context without output encoding
• SSRF: attacker controls a URL that crosses from user input into internal network requests
• Privilege escalation: lower-trust code gains access to higher-trust resources due to missing authorisation check at the boundary

Data Flow Diagrams (DFDs) and trust boundaries:
DFDs are the standard tool for visualising trust boundaries. A rectangle on a DFD represents a trust boundary (often drawn as a dashed line). Every data flow that crosses a dashed line requires: authentication (who is crossing?), authorisation (are they allowed to cross?), and input validation (is the data safe?)

Key vocabulary:
• Trust boundary — the line between two trust levels in a system; all data crossing this boundary must be validated and authenticated
• Trust level — the degree of confidence in the origin, integrity, and intent of data or a caller; lower trust = more validation required
• DFD (Data Flow Diagram) — a diagram showing processes, data stores, external entities, and data flows; trust boundaries are drawn as dashed rectangles
• Untrusted data — any data originating from a lower-trust zone; must be validated before use regardless of apparent source

The "crunchy outside, soft inside" (perimeter trust) model has been proven insufficient by every major internal breach. Each internal service is its own trust boundary.

Why perimeter-only validation fails:

Attack scenario	Why perimeter validation doesn't help
SSRF attack against internal service	Attacker bypasses API gateway by exploiting SSRF to make internal calls directly
Compromised internal microservice	Attacker controls service A; sends malicious data to service B which trusts all internal callers
Message queue poisoning	Malicious messages injected directly into Kafka/RabbitMQ; consumer service trusts queue data blindly
Data migration / batch import	Data imported from external source bypasses API gateway; processing service sees unvalidated external data

The defence-in-depth principle for validation:
Each layer validates what it cares about:
• API gateway — rate limiting, authentication, basic schema validation, WAF rules
• Service layer — business rule validation (is this a valid order amount? Is this user ID format correct?)
• Database layer — schema constraints, CHECK constraints, foreign key integrity
• Output encoding — at render time, encode for the output context (HTML, JSON, SQL)

Efficient internal validation (not duplicating perimeter work):
Internal validation doesn't redundantly repeat perimeter checks — it validates in the context of the receiving service:
• Message consumer: validates message schema against its expected format
• Downstream API call: validates that a response from a partner API conforms to the expected schema
• Background job processor: validates each record before processing, not assuming database data is always valid

Key vocabulary:
• Crunchy outside, soft inside — a derogatory term for the anti-pattern of only validating input at the perimeter while trusting all internal data; leaves internal services vulnerable to any perimeter bypass
• Defence in depth (validation) — validating data at every trust boundary, not just the perimeter; each layer validates the data in its own context
• SSRF (Server-Side Request Forgery) — an attacker tricks a server into making requests to internal resources or services, effectively bypassing perimeter controls
• Message queue poisoning — injecting malicious messages into an event queue, exploiting services that blindly trust queue contents

Each application component with different trust requirements should have its own database credential with scoped permissions. Shared credentials collapse trust levels and maximise blast radius.

Example scoped database users for an e-commerce application:

-- Web frontend user (lowest trust — internet-facing)
GRANT SELECT ON products, categories TO web_frontend_user;
GRANT SELECT, INSERT ON orders TO web_frontend_user;
-- Can view products, place orders — cannot see user PII, cannot delete

-- API service user (medium trust — authenticated users)
GRANT SELECT, INSERT, UPDATE ON orders TO api_user;
GRANT SELECT ON products TO api_user;
GRANT SELECT, UPDATE ON users WHERE user_id = current_user TO api_user;
-- Row-level security or app-enforced filtering

-- Admin backend user (high trust — internal network only)
GRANT ALL ON ALL TABLES IN SCHEMA public TO admin_user;
-- Or more specifically: GRANT SELECT, UPDATE, DELETE ON * TO admin_user

-- Read replica user (analytics — read-only)
GRANT SELECT ON ALL TABLES TO analytics_user;

Why this matters in practice:

Attack scenario	Shared credential blast radius	Scoped credential blast radius
SQL injection via frontend input	Full DB access: user PII, payment data, DROP TABLE	Frontend tables only: products, orders — no PII, no DDL
Credential leak in frontend env var	Full DB compromise	Limited to frontend's scoped permissions
Container escape from frontend pod	Full DB access from attacker's process	Only frontend's permitted tables/operations

Database-level trust boundaries beyond user permissions:
• Row-level security (RLS) — PostgreSQL RLS policies restrict which rows a user can see or modify; tenant isolation in multi-tenant applications
• Schema isolation — different components operate on different schemas; reduces accidental cross-component data access
• Connection IP allowlists — database only accepts connections from specific IP ranges/VPCs; prevents credential reuse from unexpected sources
• Audit logging — log all database operations per user; detect anomalous access patterns (frontend user doing SELECTs on admin tables)

Key vocabulary:
• Least privilege (database) — granting each database user only the minimum GRANT permissions needed; GRANT SELECT not GRANT ALL
• Row-level security (RLS) — database-enforced access control restricting which rows a user/role can see; implemented at the database layer, not the application layer
• Credential scoping — using separate credentials for each component/service with permissions matching only that component's legitimate data access
• Blast radius (credential compromise) — the maximum damage if a specific credential is stolen; determined by the GRANT permissions of that credential

Even from "trusted" partners, webhook payloads must be cryptographically verified — the network is the trust boundary, and network reachability alone does not establish trust.

Webhook signature verification process (Stripe pattern):

// Receive webhook
const rawBody = req.rawBody;          // MUST be raw bytes, not parsed JSON
const signature = req.headers['stripe-signature'];

// Stripe sends: t=timestamp,v1=hmac_sha256
// Compute expected signature:
const signedPayload = `${timestamp}.${rawBody}`;
const expected = hmacSha256(webhookSecret, signedPayload);

// Compare, reject if mismatch:
if (!timingSafeEqual(expected, received)) {
  return res.status(400).send('Invalid signature');
}

// Replay attack prevention: reject if timestamp too old
if (Math.abs(Date.now() / 1000 - timestamp) > 300) {  // 5 minutes
  return res.status(400).send('Stale webhook');
}

What signature validation prevents:
• Forged webhooks — attacker sends POST to your webhook endpoint with body {"type": "payment.succeeded", "amount": 999999}. Without verification, your system marks the order as paid without real payment.
• Content tampering — a proxy between Stripe and your server modifies the amount or status field. HMAC verification detects the modification.
• Replay attacks — attacker captures a legitimate "payment.succeeded" webhook and replays it later (charges customer once, triggers fulfilment twice). Timestamp checking within ±5 minutes prevents this.

Why HTTPS is not sufficient by itself:
HTTPS establishes that the connection goes to your server (TLS certificate verification), but it doesn't verify who is sending the request. Any HTTP client that knows your webhook URL can POST to it. HTTPS prevents eavesdropping in transit but not forgery of the request itself.

Other webhook trust boundary checks:
• Verify the webhook callback on the partner side: re-fetch the event using the event ID from the partner's API to confirm the event is real (don't act solely on webhook payload)
• Use IP allowlists if the partner publishes their webhook IP ranges
• Idempotency key: check whether you've already processed this event ID to prevent duplicate processing

Key vocabulary:
• Webhook signature verification — using HMAC-SHA256 (or similar) to verify that a webhook payload was sent by the expected party and was not modified in transit
• HMAC (Hash-based Message Authentication Code) — a cryptographic code computed over a message using a shared secret key; verifies both integrity and authenticity
• Replay attack — an attack where a previously captured valid message is retransmitted to cause the recipient to perform the action a second time
• Timing-safe comparison — comparing two strings in constant time to prevent timing-based attacks that could leak information about the expected signature value

Context switching vulnerabilities occur when data crosses a trust boundary into a new execution context without proper transformation for that context. Each target context has a specific safe handling mechanism.

Context switching security table:

Source context	Target context	Vulnerability if not handled	Safe handling
User input string	SQL query	SQL injection	Parameterised query / prepared statement
User input string	HTML output	XSS (reflected / stored)	HTML entity encoding (context-aware)
User input string	OS shell command	Command injection	Avoid shell where possible; allowlist args; subprocess with arg array
User input string	File path	Path traversal (../../etc/passwd)	Canonicalise path; verify within allowed directory
User input URL	HTTP request to that URL	SSRF	Allowlist permitted hosts/ports; block internal ranges
User input string	LDAP filter	LDAP injection	LDAP escape special characters (\28 for '(', etc.)
User input string	JSON/XML response	Injection breaking JSON/XML structure	Always serialise using JSON.stringify / XML encoder, not string concat

Root cause of all injection attacks:
Every injection vulnerability (SQL, XSS, command, LDAP, XML, SSRF) has the same root cause: data from a lower-trust context is substituted directly into the syntax of a higher-trust execution context without transformation. The countermeasure is always the same principle: separate data from instructions (parameterisation, output encoding, allowlisting).

Key vocabulary:
• Context switching (security) — when data from one execution context (user input) enters another execution context (SQL, HTML, shell); requires context-appropriate transformation
• Parameterised query (prepared statement) — a database query template with placeholders for user-supplied values; the database driver handles escaping, preventing SQL injection
• Output encoding — transforming data to be safe for the output context: HTML encoding for HTML, URL encoding for URL parameters, JSON serialisation for JSON responses
• Injection vulnerability — a class of vulnerabilities where user input changes the intended structure of a query, command, or output because data and instructions were not separated