Diagnose Ory browser login CSRF failures across cookies and proxies

When an Ory browser login fails with a CSRF or cookie error, trace one login attempt from initialization through submission. Check that the browser retained the cookies established for that attempt, that the form uses its flow data, and that the action URL reaches the intended public endpoint. Ory’s browser flow documentation explicitly requires the correct CSRF cookies when retrieving a flow and describes cookies as part of browser-flow security. Ory self-service flows

A visible login form does not establish that those requirements are satisfied. The useful diagnostic is a request timeline that connects the initialization response, stored cookies, fetched flow, and submitted form.

This is a documentation-based investigation procedure, not a report of a reproduced incident. The self-hosted configuration checks below apply to Ory Kratos; managed Ory Network deployments require their own supported domain and integration configuration.

Identify the browser flow before changing cookie settings

Ory distinguishes browser flows from native/API-client flows. Browser initialization uses an endpoint such as /self-service/login/browser; native flows have a different initialization path and security model. Receiving JSON does not make a request a native flow: the browser flow also supports JSON responses for client-side applications. Self-service client types

Record the initialization URL and returned flow type. If you are building a browser application, compare its requests with the browser-flow documentation. Do not change to a native flow merely to make a cookie error disappear.

Next record the flow identifier and the form’s action URL. Ory returns UI information with the flow, including an action, method, and nodes used to render the form. Inspect those returned values before debugging a separately constructed submission URL. Flow rendering and submission

For a custom login interface, this is the boundary between visual rendering and authentication integration. The broader custom login experience guide covers the surrounding account journeys; this procedure focuses on one failing request chain.

Build a four-stage request timeline

Use a disposable account and capture one clean attempt in browser developer tools. Retain sanitized metadata rather than passwords, cookie values, or tokens.

Stage	What to inspect	Question it answers
Initialize	Public URL, response status, redirects, cookie attributes	Did this attempt establish browser state at the intended host?
Retrieve flow	Flow ID, request URL, attached cookies	Is the UI reading the same attempt with the necessary cookie context?
Render	Returned action, method, and CSRF input node	Does the form represent the returned flow data?
Submit	Actual destination, method, cookies, and presence of CSRF field	Did the browser submit the form with its associated state?

This timeline is a diagnostic framework. It does not prescribe a single rendering architecture or claim that every failure has the same cause.

Ory’s documented form example includes a hidden csrf_token input. Inspect whether your form handling preserves the returned input, rather than only rendering the fields visible to the user. Do not log its value while checking its presence. Ory browser form example

If the form was rerendered during the attempt, compare its current flow ID and action with the submission. Treat a mismatch as an integration discrepancy to investigate before altering security settings.

Diagnose the cookie at the point it disappears

If a response includes a cookie but the browser does not store it, inspect the browser’s rejection information and the response attributes. If the browser stores it but does not send it, inspect the outgoing request URL and cookie scope. These are different observations and should lead to different checks.

For self-hosted Kratos, Ory documents secure cookies and warns about running HTTP without development mode. It also identifies inconsistent use of localhost and 127.0.0.1 as a cause of cookie problems. Keep the hostname consistent throughout local initialization, UI navigation, and submission. Do not use development-mode configuration as a production repair. Self-hosted CSRF troubleshooting

Inspect anti-CSRF and session cookies independently. Ory’s configuration documentation separates shared cookies settings from overrides under session.cookie. A change to session-cookie scope is not a reason to assume that the anti-CSRF cookie now has the same scope. Advanced cookie settings

Record the effective domain, path, and relevant security attributes of the cookie involved in the failing request. Avoid a broad cookie-policy change until you have identified which cookie is missing and where.

Compare the proxy’s external URL with the returned action

For self-hosted Kratos, Ory documents serve.public.base_url as an input to redirect and form-action URL generation. Compare the action returned in the flow with the externally reachable URL you intended users to access. Public base URL

A useful proxy worksheet has four entries: browser-facing scheme and hostname, public path prefix, upstream destination, and generated form action. Investigate any disagreement. For example, if the returned action names a host the browser was not intended to visit, inspect the public base URL and routing configuration before rewriting the form in application code.

Ory’s self-hosted troubleshooting guide recommends serving the application and public identity endpoints on the same domain and describes routing separate paths through a reverse proxy. This is guidance for that deployment context, not proof that every multi-domain product configuration is unsupported. The advanced settings documentation separately identifies Multibrand support in Ory Network and Kratos Enterprise. Self-hosted domain guidance · Advanced domain settings

Verify the repair with a fresh attempt

After correcting the identified discrepancy, start a fresh flow and repeat the timeline. Document which observation changed: the cookie is now stored, attached to the intended request, or accompanied by the correct form data. Do not treat the disappearance of one error message as proof that the complete login works.

Then exercise unsuccessful cases appropriate to your integration, such as a missing CSRF input and a request without the associated browser cookie. Confirm that your application handles failures without granting access. These are proposed acceptance checks; execute them in the deployment you will release and record actual outcomes.

Keep the resulting runbook small: deployment type, public URLs, flow entry point, cookie scope, failing stage, correction, and verification result. For broader application mutations beyond Ory’s login flow, use the separate CSRF defense guide rather than assuming that fixing login establishes protection for every application endpoint.