Secure browser origin boundaries

System and boundaries

Inventory the browser-visible system by origin, not only by application name. An origin is primarily scheme, host, and port. List every production, administrative, upload, download, static asset, API, identity, support, and third-party origin that participates in the user flow.

For each origin, record:

• Who controls DNS, hosting, deployment, and TLS.
• Which scripts execute with that origin's authority.
• Which cookies are sent and whether they are host-only, secure, HTTP-only, and same-site.
• Which storage, service workers, caches, and browser APIs are available.
• Which other origins can frame it, message it, cause requests to it, or read its responses.
• Which sensitive data and actions it exposes.

Do not use paths as script-isolation boundaries. /admin and /app on one origin normally share script authority. Put a less-trusted application, user content, or third-party-heavy surface on a separate origin when compromise should not grant the main application's authority.

Treat third-party script as code inside your origin. It can read the page, call same-origin APIs, observe user input, and change displayed transactions. Reduce script suppliers, pin or control delivery where practical, and avoid giving a marketing or support script access to an administrative origin.

Request and decision flow

Trace one state-changing browser action, such as adding an administrator:

1. The browser loads the application from its origin.
2. The browser attaches the Pomerium and application session state under their cookie rules.
3. Application script sends the exact API request.
4. The route enforcement point authenticates and authorizes broad access.
5. The application validates CSRF intent, subject, object, action, tenant, and current state.
6. A high-impact action requires fresh authentication or transaction confirmation bound to the exact new administrator.
7. The application commits one atomic change and records the final result.

Now trace the same action from an attacker-controlled origin. The browser may still send a form, image, link, or selected Fetch request. Same-origin policy often prevents the attacker from reading the response. It does not prove the request was harmless. CSRF controls must reject the state change.

Trace a permitted cross-origin application. CORS grants that exact origin permission to read selected responses. It does not authenticate the user or authorize the object. The endpoint repeats all application decisions. Credentialed CORS is narrow and intentional.

For frames and messages, name each sender and receiver. Use a fixed postMessage target origin and validate the sender origin, message type, schema, state, and authority. A message that says approve: true is data from another principal, not an application decision.

Failure domains

Test compromise and configuration failures:

• XSS in the main application.
• XSS or host takeover in an allowed CORS origin.
• Compromise of a third-party script supplier.
• A broad parent-domain cookie or wildcard host rule.
• An attacker page that submits a credentialed state-changing request.
• A permissive CORS origin matcher or reflected origin.
• Framing of a sensitive action under deceptive content.
• A postMessage receiver that accepts any origin or loose schema.
• Stale service-worker code after an application migration.
• Logout that clears one session but leaves another application session active.

Use browser tests that inspect network requests, cookie attachment, preflight behavior, response readability, frame policy, message origin, final state, and visible confirmation. Do not infer protection from one response header in isolation.

Design tradeoffs and residual risk

One origin simplifies sessions, deployment, and navigation. It joins script and storage authority. Separate origins improve isolation and add CORS, messaging, cookie, navigation, and logout complexity. Strict cookie and frame controls can break federation or embedded workflows. A strict Content Security Policy reduces XSS impact and requires disciplined script delivery.

Record the reason each cross-origin trust exists. Remove it when the integration ends. Keep sensitive actions resilient to a compromised browser script through narrow authorization, fresh user confirmation, and visible transaction details where consequence requires it.

Pomerium boundary

Pomerium can authenticate browser access, apply route policy, manage its own session, and pass signed identity context to an upstream. Operators choose protected hosts and must deploy each application so direct origins do not bypass the route.

The upstream owns application cookies, CSRF, CORS, CSP, frame policy, browser storage, service workers, messages, third-party script, object authorization, transaction confirmation, and application logout. Two applications under one protected host still share browser origin authority even if Pomerium routes them by path.

Exercise

Create an origin inventory for one user and administrative application. Draw these flows:

1. Normal same-origin read and state change.
2. Cross-origin request that must be rejected.
3. Approved CORS read.
4. Embedded frame and message exchange.
5. XSS or third-party-script compromise.
6. Login, session renewal, reauthentication, and logout.

For each flow, mark the session credential, automatic browser behavior, read boundary, intent signal, route decision, application decision, transaction confirmation, and final evidence. Run tests from a separate attacker origin and from each approved integration origin.

Evaluation checklist

• Are all browser origins and their deployment owners known?
• Do applications that need separate script authority use separate origins rather than paths?
• Is each cookie scoped to the narrowest host, path, security, HTTP access, and same-site behavior that works?
• Are CORS, CSRF, authentication, route policy, object permission, and transaction confirmation distinct controls?
• Does every frame and message exchange validate exact origins and typed data?
• Can third-party or compromised same-origin script perform a high-impact action without fresh, bound confirmation?
• Do login, renewal, failure, and logout tests cover every session layer?