Cypress Cross-Origin Error: Test Multi-Domain Flows

Your test clicks 'Log in with SSO', the browser lands on your identity provider, and Cypress dies with a cross-origin error. The login form is right there — you can see the username field — but every command you send is refused. It feels like Cypress gave up one step from the finish line.

It did not give up; it hit a browser security wall. Cypress commands execute inside your app's origin, and the same-origin policy forbids them from reaching into the provider's page. Before cy.origin() existed, teams resorted to API-login workarounds, disabled security, or simply did not test SSO at all. Now there is a first-class answer: run those commands inside the second origin, pass data across safely, and come home with a valid session.

This article shows you exactly that. You will learn the cy.origin() shape — origin string, args, callback — why the callback cannot see your variables, how to pair it with cy.session() so multi-domain logins run once instead of per test, and when to sidestep the whole problem with same-super-domain design. Multi-domain flows stop being the tests everyone skips.

Why Cypress Throws a Cross-Origin Error

Browsers isolate origins — scheme, host, and port together — so a script running in https://app.example.com cannot read or write the DOM of https://auth.example.com. Cypress commands are scripts running in your app's origin, which means the moment a test lands on a second origin, every cy.get() and cy.type() is a cross-boundary access the browser must refuse. Cypress surfaces that refusal as the cross-origin error instead of letting commands silently operate on the wrong document.

This bites exactly where modern apps delegate: single sign-on providers, OAuth consent screens, payment checkouts, and headless CMS previews. Each hands the browser to a domain you do not control, then redirects home. Tests written when auth was a same-origin form keep working until the migration week, then fail at the first keystroke on the provider's page — while manual QA passes everything, hiding the automation gap.

Recognize the signature early: the error names two origins, and the failing line touches the foreign page. That combination never means a bad selector or a slow load — it means an origin boundary stands between your commands and the DOM. Either bring the commands across with cy.origin() or remove the boundary with same-super-domain design. Everything else in this article is execution of one of those two moves.

// The wall: plain commands cannot cross origins
cy.visit('/')
cy.contains('Log in with SSO').click()
// Browser is now at https://auth.example.com/login
cy.get('#username').type('qa@example.com')
// ^ CROSS-ORIGIN ERROR: commands still run in the app origin,
//   but the page (and its DOM) belongs to auth.example.com

// Same failure shape on payment and CMS redirects:
// app.example.com -> payments.provider.com -> app.example.com

cy.origin(): The Multi-Domain Escape Hatch

The cy.origin() command takes an origin string, an optional args object, and a callback — and executes that callback inside the secondary origin with the Cypress runtime injected there. Commands inside the block target the foreign page normally: get, type, click, and even cy.visit() scoped to that origin. When the callback finishes, control returns to the primary origin and the test continues where the redirect left it.

The origin string must match exactly, including protocol and port — https://auth.example.com is not http://auth.example.com and not https://auth.example.com:8443. Copy it from the URL bar during a manual walkthrough rather than typing it from memory. A near-miss produces a mismatch error that reads like a Cypress bug but is really a typo.

Keep each block focused on one origin and assert the handoff on both sides: the provider shows its challenge (username field visible) before you type, and your app shows the authenticated state (user menu, dashboard URL) after you return. Those two assertions turn silent redirect failures — landing back logged-out — into loud, precisely located errors. Multi-origin tests are inherently harder to read, so the assertions double as documentation of the expected journey.

// cy.origin(): run commands inside the secondary origin
cy.visit('/')
cy.contains('Log in with SSO').click()

cy.origin(
  'https://auth.example.com',
  { args: { username: 'qa@example.com', password: 's3cr3t!' } },
  ({ username, password }) => {
    // Everything here executes IN auth.example.com
    cy.get('#username').type(username)
    cy.get('#password').type(password, { log: false })
    cy.get('button[type="submit"]').click()
  }
)

// Back on the app origin: prove the round-trip worked
cy.url().should('include', '/dashboard')
cy.get('[data-testid="user-menu"]').should('contain', 'QA')

Passing Data With args: The Serialization Rule

The cy.origin callback travels to the secondary origin as serialized text, not as a live closure — which means it arrives without your variables, imports, or helper functions. Anything the callback references from the outer scope is undefined when it runs. This is the single most confusing cy.origin behavior, and it is a direct consequence of executing code in another origin's context.

The args option is the sanctioned bridge: a plain object of serializable values (strings, numbers, booleans, plain objects, arrays) that Cypress carries across and injects as the callback's parameter. Credentials, test emails, and feature flags cross this way. Functions, class instances, DOM nodes, and Cypress chainables do not survive — if the callback needs logic, define it inside the callback body.

Design callbacks to be self-contained: destructure args in the signature, use only commands and plain code inside, and keep the block short. Long callbacks that smuggle half the test through args become unreadable and brittle. If a provider flow needs elaborate logic, extract it into a custom command whose body is the cy.origin call — the command boundary keeps the serialization rule visible instead of surprising the next reader.

Same-Super-Domain Design: Avoid cy.origin Entirely

When you own both sides of a multi-domain flow, the cheapest fix is removing the boundary instead of crossing it. Pages on the same super-domain — app.example.com and auth.example.com — can be unified behind one test origin with a reverse proxy, path-based routing (/auth served by the provider behind your domain), or environment config that colocates them. Single origin means plain Cypress commands throughout: no cy.origin, no serialization rules, faster tests.

This is a design decision with compounding returns. Provider-hosted pages you do not control (public SSO, Stripe checkout) still need cy.origin, but every first-party handoff you unify deletes an entire category of test complexity. Raise it during architecture reviews, not after the suite breaks: asking 'can test reach both pages on one origin?' costs nothing at design time and rewrites weeks of test maintenance later.

Be honest about the trade-off. Proxying auth in test environments diverges from production topology, so keep one smoke spec running against the real split domains (with cy.origin) to prove the production shape works. Unify for speed and simplicity across the suite; verify reality with a focused few. That layered approach gives you maintainable tests without lying to yourself about what production looks like.

Sessions and Cookies Across Origins With cy.session()

A full provider round-trip costs seconds per test — unacceptable multiplied across a suite. cy.session() solves it by running the login once, caching the resulting cookies, local storage, and session storage, then restoring them for later tests. The critical structural rule: cy.session() goes outside, cy.origin() goes inside its setup function. The session wraps the whole multi-origin journey.

Validation decides whether the cache is trustworthy. Assert the authenticated state inside the setup (dashboard URL, user menu) so a failed login never gets cached as success, and add a validate function hitting a session endpoint like /api/whoami so stale sessions are detected and rebuilt. Without validation, an expired session restores a logged-out ghost into every test and the failures scatter across unrelated specs.

Reversed nesting — cy.origin outside, cy.session inside — breaks because the session cache cannot coherently span the boundary from within the foreign origin. If your sessions mysteriously re-run setup every test or restore empty, check the nesting first. Session outside, origin inside, validation always: that shape scales from one SSO spec to hundreds without growing suite time.

// Login once, reuse everywhere: cy.session outside, cy.origin inside
Cypress.Commands.add('loginViaSSO', (username, password) => {
  cy.session(
    username,
    () => {
      cy.visit('/')
      cy.contains('Log in with SSO').click()
      cy.origin(
        'https://auth.example.com',
        { args: { username, password } },
        ({ username, password }) => {
          cy.get('#username').type(username)
          cy.get('#password').type(password, { log: false })
          cy.get('button[type="submit"]').click()
        }
      )
      // Validate INSIDE setup so only good sessions are cached
      cy.url().should('include', '/dashboard')
      cy.get('[data-testid="user-menu"]').should('be.visible')
    },
    {
      validate() {
        cy.request('/api/whoami').its('status').should('eq', 200)
      },
    }
  )
})

Multi-Hop Flows: Sequencing Three or More Origins

Real flows chain multiple hops: app to CMS preview to payment provider and home again. The rules that keep these debuggable are simple but strict. One cy.origin block per origin, sequenced at the test's top level — callbacks cannot contain further cy.origin calls, so nesting is not merely ugly, it is illegal. Assert the URL and a visible outcome after every hop so a failed redirect is caught at the hop, not three pages later.

Keep each hop's args minimal and explicit: the card number for the payment block, the article slug for the CMS block. Minimal args make each block readable in isolation and prevent accidental coupling where the payment step depends on variables from the auth step. Shared setup (login) belongs in cy.session-backed helpers that run before the journey starts.

When the chain grows beyond two hops, resist covering the full journey in every test. Test each handoff in its own spec and keep one end-to-end smoke test for the complete chain. Full-chain tests are inherently slower and more brittle; concentrating that cost in a single spec while the handoffs enjoy focused coverage gives you the same confidence at a fraction of the flakiness. Keep the smoke test's hops few and its assertions loud.

// Three-origin checkout: sequence hops, never nest
it('completes checkout across app, CMS, and payment origins', () => {
  cy.loginViaSSO('buyer@example.com', 's3cr3t!') // app origin, cached
  cy.visit('/checkout')
  cy.get('[data-testid="pay-now"]').click()

  // Hop 1: payment provider (its own block, top level)
  cy.origin(
    'https://payments.provider.com',
    { args: { card: '4242424242424242' } },
    ({ card }) => {
      cy.get('#card-number').type(card)
      cy.get('#pay').click()
    }
  )

  // Back home: prove each handoff before continuing
  cy.url().should('include', '/order-confirmed')
  cy.get('[data-testid="order-number"]').should('be.visible')
})