The code reads two settings (the app's own web address and a list of trusted addresses) from the server's environment so the login system knows which addresses to trust. This is a normal way to configure a self-hosted app, and the values are not shared with anyone.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment. The match applies to this repository.
Contextual assessment: The flagged line reads APP_URL and TRUSTED_ORIGINS from process.env, which are configuration inputs for the better-auth instance (baseURL and trustedOrigins). The values stay local to the auth setup and are never serialized, logged, or sent to any external destination. Reading environment variables for server configuration is standard practice for a self-hosted app and matches the project's stated purpose. The scanner signal is a false positive triggered by environment-variable access.
The code contains default web addresses like 'localhost' with port numbers, which are just the app's own local development addresses. Nothing is being sent to an outside server.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link. The match applies to this repository.
Contextual assessment: Detailed technical wording was omitted by the public report safety filter.
Session cookies are never marked Secure, even on HTTPS deployments
low risk · medium confidence
The login cookie is never marked as 'secure only', so on setups where the app is accessed over an encrypted connection, the cookie could still travel over an unencrypted one in some situations. This is a small safety gap, not an active problem for typical local use.
Technical assessment
The advanced.useSecureCookies=false setting is unconditional. The comment explains it exists to support plain-HTTP LAN deployments, but when an operator sets APP_URL to an https origin, the session cookie is still sent without the Secure flag, so it could be transmitted over an unencrypted connection if the browser is directed to an http URL for the same host. This is a hardening gap rather than demonstrated exposure, and it matches the project's documented plain-HTTP self-hosting use case.
Impact: low · Exploitability: unlikely
Developer action: Consider deriving the Secure cookie behavior from the APP_URL scheme (Secure when the configured origin uses https) instead of disabling it unconditionally, so HTTPS deployments get hardened cookies while plain-HTTP LAN use keeps working.