Does Replit Auth set HttpOnly, Secure, and SameSite on its session cookie?

Replit Auth handles session storage on Replit's own domain, so the cookie attributes are set by Replit's server rather than by code Replit Agent wrote into your project. For applications that route login through Replit Auth, the attributes are a known quantity. For hand-rolled login built on top of passport or flask-login, the defaults follow the library and Agent does not change them.

Will my login break if I add SameSite=Strict on a Replit-hosted app?

Yes, in many cases. SameSite=Strict blocks the cookie on any cross-site navigation, including a return from an OAuth provider, a deep link arriving from an email client, or a payment redirect from Stripe. For most session cookies, SameSite=Lax gives the same protection against cross-site form posts without breaking those flows. Reserve Strict for a separate high-privilege action cookie.

Does Replit set the Secure flag on cookies for me at the proxy?

No. Replit's load balancer terminates TLS and forwards the request to your app, which means the connection your code sees may look like HTTP unless app.set('trust proxy', 1) is configured on Express, or the equivalent is set on Flask and Django. Without that, a secure: true flag silently drops the cookie because the framework still believes the connection is HTTP.

Can the Replit secret scanner catch missing cookie flags?

No. The Replit secret scanner inspects source code for known credential formats such as OpenAI keys, Stripe keys, and AWS access keys. It does not parse middleware configuration or HTTP response headers, so missing HttpOnly, Secure, or SameSite attributes are not part of its detection set. A manual DevTools check or a curl read of the Set-Cookie header covers this gap.

If my Capacitor app reads the cookie inside the WebView, do these flags still matter?

Yes. A Capacitor WebView runs JavaScript exactly like a browser, so a missing HttpOnly exposes the session token to any ad SDK or analytics widget the app loads. OWASP MASVS treats cookie attribute hygiene as a baseline expectation for mobile apps that hold authentication state in a cookie, and the same rule applies to embedded Android WebView and iOS WKWebView clients.

Does Replit Agent use secure cookies by default?

You shipped a Flask or Express backend on Replit using Replit Agent, wired your mobile WebView, React Native client, or browser frontend up to it, and now you are wondering whether the session cookies the server sets carry the three flags every browser expects in 2026. The honest answer is no, not unless the prompt asked Agent for them or you edited the code by hand.

Short answer

Replit Deployments serve every public URL over HTTPS, which makes the Secure attribute usable, but Replit Agent does not consistently set HttpOnly, Secure, or SameSite on session cookies in the code it generates. A 2025 analysis from VibeAppScanner reported that insecure cookies appear in roughly 20 to 40 percent of vibe-coded deployments across Replit, Lovable, Bolt.new, and v0.dev. Replit's own secure vibe coding guide asks builders to add the three flags themselves.

What you should know

Replit Deployments serve HTTPS, but the Secure flag still needs to be set in code. HTTPS protects the transport; the cookie attribute tells the browser to refuse to send the cookie over plain HTTP, including any redirect a proxy might generate.
Replit Agent often omits HttpOnly on session cookies. Without HttpOnly, any cross-site scripting hit reads document.cookie and walks away with the session token.
SameSite defaults to Lax in modern browsers when unset. That partially covers cross-site request forgery, but the default behavior is not identical across Chrome, Firefox, Safari, and older Android System WebView versions.
Replit Auth handles session cookies for you. Apps that route login through Replit Auth get a reasonable default. Hand-rolled sessions are where the gaps live.
VibeAppScanner observed insecure cookies in 20 to 40 percent of vibe-coded deployments in 2025. That figure covers Replit Agent alongside Lovable, Bolt.new, and v0.dev.
Mobile WebViews and Capacitor apps inherit the same cookie flags. A WebView talking to a Replit backend reads Set-Cookie headers the same way a desktop browser does.

What does Replit Agent actually set on session cookies?

In most generated code, Replit Agent calls express-session, flask-session, or next-auth with the default options. Those defaults vary by library, but none of them set Secure to true automatically, and only some set httpOnly to true without explicit configuration. Express's cookie-session middleware, for instance, sets httpOnly by default but leaves secure as false, which means the cookie is sent over plain HTTP if the browser ever sees one.

The cause is template fidelity. Agent copies patterns from Stack Overflow answers, framework READMEs, and tutorial repositories. The majority of those examples are written for local development, where HTTPS is not available, so the patterns ship to production without ever flipping secure: true.

Each missing flag closes a specific class of attack. HttpOnly blocks JavaScript from reading the cookie through document.cookie, which is the defense against cross-site scripting that lifts session tokens. Secure tells the browser to send the cookie only over HTTPS, which removes the long-tail risk of a redirect or captive Wi-Fi portal sending it in plain text. SameSite controls whether the cookie travels on cross-site requests: Lax allows top-level navigations (most login flows survive), Strict blocks everything cross-site, None permits cross-site sending and requires Secure. OWASP treats the three as the minimum bar for any cookie carrying authentication state. Replit's own secure vibe coding guide instructs builders to set the three attributes correctly. Agent does not enforce that line during generation.

Does Replit Auth handle this for you?

Yes, if the app uses Replit Auth for login. The hosted Replit Auth flow manages the session token on Replit's domain and returns the result to your app, which means the cookie attributes are set by Replit's own server, not by code Agent wrote. For applications where Replit Auth is acceptable, this is the path of least friction.

Hand-rolled login with passport, flask-login, or a custom database query against users is where Agent's cookie defaults bite. The session middleware is configured locally in your project, the defaults follow the library, and the attributes the browser sees depend entirely on what Agent typed. Auditing those few lines is the single highest-value fix.

How do I check the cookies my Replit app sends right now?

A two minute check answers the question. Open the deployed URL in Chrome, log into a test account, then open DevTools, Application, Cookies, and select the deployment domain. Look at the row for the session cookie:

Is the HttpOnly column checked? If not, every script in your app can read it.
Is the Secure column checked? If not, a redirect can leak it in plain text.
What value sits in SameSite? Empty means the browser is defaulting it, which is not the same as you setting it.

The same view is available in Safari Web Inspector and Firefox Storage Inspector. For a non-interactive check, run curl -i https://your-app.repl.co/login and read the Set-Cookie header directly. The attributes appear as a semicolon-separated list, and what is not in the header is not set. Replit's secret scanner catches token values but does not inspect cookie flags, so the manual read still matters.

How do I add the flags in Express, Flask, and Next.js?

The fix is a few lines per framework. The table below summarizes the exact configuration to ask Replit Agent for, or to write by hand.

Stack	Library	Insecure default	Secure configuration
Express on Node	`express-session`	`cookie: { secure: false, httpOnly: true }`, `sameSite` unset	`cookie: { secure: true, httpOnly: true, sameSite: 'lax' }` plus `app.set('trust proxy', 1)`
Express on Node	`cookie-session`	`httpOnly: true`, `secure: false`	`secure: true, sameSite: 'lax'`
Flask on Python	`Flask-Session` or `flask.session`	`SESSION_COOKIE_SECURE = False`	`SESSION_COOKIE_SECURE = True`, `SESSION_COOKIE_HTTPONLY = True`, `SESSION_COOKIE_SAMESITE = 'Lax'`
Next.js	`next-auth`	`useSecureCookies` false in dev	`useSecureCookies: true` in production, automatic when `NEXTAUTH_URL` starts with `https`
Django	`django.contrib.sessions`	`SESSION_COOKIE_SECURE = False`	`SESSION_COOKIE_SECURE = True`, `SESSION_COOKIE_HTTPONLY = True`, `SESSION_COOKIE_SAMESITE = 'Lax'`, `CSRF_COOKIE_SECURE = True`

For Express specifically, the trust proxy setting matters on Replit because requests reach your app behind a load balancer that terminates TLS. Without it, req.secure is false and secure: true cookies are silently dropped. After the change, redeploy, clear cookies, log in again, and verify the flags in DevTools before declaring the fix done.

What changes when the client is a mobile WebView or Capacitor app?

The flags do not change, but the consequences of getting them wrong do. A WebView shipped inside a Capacitor or Cordova app, or an embedded Android WebView inside a native shell, runs JavaScript that has the same document.cookie access a browser does. A missing HttpOnly exposes the session to any ad SDK, analytics widget, or untrusted third-party script the app loads. The OWASP MASVS MSTG-PLATFORM control set treats this as a baseline expectation for any mobile app that stores authentication state in a cookie.

For React Native or Flutter apps that call the Replit backend over HTTPS but parse JSON rather than rendering a WebView, the cookie story is simpler: the native HTTP client respects Set-Cookie headers, but a missing HttpOnly is irrelevant because there is no DOM. The Secure and SameSite flags still matter; Secure because some HTTP libraries follow redirects through HTTP, and SameSite because a deep link can sometimes trigger a cross-site request the cookie should not ride.

What to watch out for

A few patterns trip even careful builders.

Setting SameSite=None without Secure. Browsers reject the combination outright. Agent occasionally writes sameSite: 'none' to support an embedded iframe, then leaves secure: false. The cookie is never set.
Trusting the browser default for SameSite. The default is Lax in current Chrome and Firefox, but Safari was slower to adopt the change, and Android System WebView versions older than 96 do not enforce the default. Set the attribute yourself.
Forgetting app.set('trust proxy', 1) on Express behind Replit's load balancer. Without it, secure: true cookies are silently dropped because Express thinks the connection is HTTP.
Mixing session cookies with preference or analytics cookies under the same flags. Non-auth cookies have different requirements; copying the session attributes onto a marketing cookie can break GDPR consent flows.
Assuming the Replit secret scanner covers cookies. It scans for known token formats in code, not for missing cookie attributes in HTTP headers.

Key takeaways

Replit Agent does not set HttpOnly, Secure, and SameSite on hand-rolled session cookies by default. Audit the middleware configuration before deploy.
Replit Auth is the path of least friction if it fits the product. It handles the attributes on its own domain.
A two minute DevTools check on the deployed URL surfaces the issue. Empty columns under HttpOnly, Secure, or SameSite mean a fix is owed.
For Express on Replit, remember the trust proxy setting alongside the cookie flags. Otherwise the Secure flag fights the load balancer and the cookie never lands in the browser.
For mobile builders who want an external read of their compiled WebView or Capacitor build, PTKD.com (https://ptkd.com) is one of the platforms that scan packaged APK, AAB, and IPA bundles for OWASP MASVS findings, including authentication storage and cookie handling inside embedded WebViews.