How to Test Secure Cookies and Auth Flows in Local Development

Use a real HTTPS origin in development for secure cookies, browser auth behavior, embedded flows, and feature checks that do not behave the same way on plain HTTP localhost.

A lot of 'local auth problems' are really secure-origin problems. When the browser expects HTTPS for a cookie, redirect, or embedded workflow, Bore gives the local app an origin that behaves more like production.

secure cookies local devlocal auth flow httpshttps localhost cookies

Install Bore

curl -sL https://bore.dk/install.sh | bash

Closer to production browser behavior

Useful for auth and embedded flows

Can separate app and API origins when needed

How It Works

Simple local workflow, real HTTPS externally

Step 1

Run the local app or auth surface

Start the frontend or backend that needs secure-origin browser behavior.

Step 2

Expose it with Bore

Use Bore to provide the HTTPS origin that the browser will treat as secure.

bore up 3000

Step 3

Test the flow against the HTTPS URL

Repeat the cookie, auth, iframe, or callback scenario using the Bore hostname instead of plain localhost.

Step 4

Split origins when required

If the app and API should be on different hosts, reserve a child host under the same namespace.

Where Bore Differs

Bore can keep HTTPS on reserved child hosts too

Most tunnel workflows stop at one public hostname. Bore can keep your main app on one HTTPS namespace and reserve a child host like `api.<namespace>.bore.dk` for a second local service.

bore host add <namespace> api
bore host set-port <namespace> api 3001

That matters when frontend and API origins need to stay separate in local development, or when webhook, auth, and admin traffic should not all share one hostname.

FAQ

Common questions

Why is localhost not enough for some auth flows?

Some browser and provider behaviors depend on a secure origin or a realistic host setup. A public HTTPS URL often reproduces the production behavior more accurately.

Can this help with secure cookie testing?

Yes. Bore gives the local app a proper HTTPS origin, which is useful when you need to test secure-cookie behavior outside plain localhost assumptions.

Can I keep the frontend and auth API on different origins?

Yes. Bore can route the main hostname and a child host such as api.<namespace>.bore.dk to different local ports.

Related Guides

More HTTPS development guides

View all guides