Web Security / Basic: web trust and identity contracts / Lesson 1

HTTP and web trust boundaries

Trace a request through browser, transport, application, and data boundaries before deciding what a security signal proves.

About 4 min readContent reviewed 2026-10-26

On this page

Lesson goals

Distinguish HTTP semantics from application permission.
Describe origins, sites, intermediaries, and trusted context.

Follow the complete request and response path

A web request crosses several decision points: a browser chooses a destination, transport protects a connection, an intermediary may route or cache it, and the application interprets data and applies policy. Each point has different information and authority. A successful connection is not proof that a record may be disclosed, and a successful HTTP status is not proof that the business task succeeded. Use a fictional reading portal to name the subject, resource, action, and intended outcome. This model makes it possible to ask which layer should enforce a rule instead of placing every check in the visible form.

Keep method meaning and state change aligned

RFC 9110 defines HTTP semantics including safe and idempotent methods, representations, and status meaning. Safe means the client does not request a state-changing action through that method’s semantics; incidental server logging can still occur. Idempotent concerns the intended effect of repeated identical requests, not identical response bytes or freedom from all side effects. Do not put a destructive application action behind an ordinary navigation GET and expect browser controls to repair the design. Choose methods and responses intentionally, then enforce authorization and request authenticity independently. The course reads synthetic records only and sends no HTTP traffic.

Record what the application must verify

The example names a proposed edit operation and separates transport, identity, permission, and request-authenticity questions. It is a planning record, not a server route or a security configuration. A real implementation obtains trusted subject context from its authentication boundary and loads resource scope from trusted storage. Values supplied in a browser request are claims until validated; a user-controlled owner id cannot become authority merely because it is syntactically valid. Keep the response contract clear so rejection leaves protected state unchanged and avoids revealing private details.

json A synthetic request-boundary record

{
  "operation": "edit-reading-note",
  "method": "POST",
  "transportRequired": "authenticated-HTTPS",
  "subjectRequired": "validated-session",
  "permissionRequired": "assigned-note-editor",
  "requestAuthenticity": "reviewed-for-session-model",
  "rejectionEffect": "no-protected-mutation"
}

The file configures no route and contains no real session. It states separate requirements rather than claiming any is implemented. Platform-specific middleware and actual browser behavior require their own approved verification.

Distinguish origin from site and identity

An origin is based on scheme, host, and port. A site is a different browser concept used by policies such as SameSite cookies and can group origins under documented rules. Neither identifies a human user or proves permission. The local parser below normalizes two synthetic HTTPS locations and compares their origins without contacting either host. It illustrates one narrow browser-boundary concept, not a complete URL validator or access-control engine. Cookies, CORS, and same-origin restrictions use different rules and should not be blended into a single idea that internal or familiar-looking means trusted.

javascript A complete offline origin comparison

const first = new URL("https://portal.example.invalid/notes")
const second = new URL("https://portal.example.invalid:443/profile")
const other = new URL("https://media.example.invalid/notes")
if (first.origin !== second.origin || first.origin === other.origin) {
  throw new Error("ORIGIN_MODEL_MISMATCH")
}

Runs under Node using reserved example domains and local parsing only. The explicit default HTTPS port normalizes to the same origin; the different host does not. No DNS lookup, browser request, or security enforcement occurs.

Review the boundaries an intermediary introduces

Reverse proxies, caches, and load balancers can alter which metadata reaches the application and which responses are reused. Trust forwarded identity or client-address headers only through an explicit trusted-proxy configuration; arbitrary request headers are not verified facts. Cache keys and response policy must prevent private content being served across users. Record the actual deployment assumptions and test them in an authorized isolated environment. A local parser cannot establish proxy behavior. Security review should connect protocol semantics, browser rules, application policy, and data ownership while preserving uncertainty about layers that have not been tested.

Common errors and fixes

HTTPS is treated as permission to read a record

Why it happens: Transport authentication is confused with application authorization.
How to fix it: Check subject, resource, and action at the trusted service boundary.
Prevent it next time: Review each security claim separately.

A GET navigation changes sensitive state

Why it happens: Application behavior violates the intended safe-method contract.
How to fix it: Redesign the operation and its independent authorization/authenticity checks.
Prevent it next time: Test state changes by method and route.

A client-supplied header becomes trusted identity

Why it happens: The proxy and application trust boundary is undefined.
How to fix it: Use approved trusted-proxy and identity integration rules.
Prevent it next time: Document and verify intermediary assumptions.

Check your understanding

1. Two URLs share a host but use different schemes. Are they necessarily the same origin?

Show worked solution

No. Scheme is part of the origin tuple, along with host and port. Compare the normalized origins under browser rules, then evaluate site, cookie, and authorization policies separately. Similar-looking locations do not establish the same trust claim.

2. A request returns 200 but updates the wrong user’s note. What failed?