The code reads two settings from the server's environment (the app's own URL and a list of allowed origins) so the login system knows where it is running. Nothing is sent anywhere; the values stay in the app's own configuration. This is normal and expected for self-hosted software.
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 environment access consists of reading APP_URL and TRUSTED_ORIGINS from process.env at module scope to configure the better-auth instance's base URL and trusted-origin list. The values are used locally for authentication configuration; there is no serialization of environment contents, no credential extraction, and no transmission of the read values to any external destination. This is standard, disclosed server configuration for a self-hosted app whose README explicitly tells operators to set these variables.
The only web addresses in this code are default local addresses (the app running on your own machine). They are used to configure the login system for local use, not to send data to anyone else. This matches the project's stated self-hosted purpose.
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 never marked Secure, even when the app is served over HTTPS
low risk · high confidence
Login cookies are never marked as HTTPS-only, even when the app is set up with a secure web address. That is a deliberate choice so the app works on home networks without encryption, but it means the login cookie could be intercepted if someone uses the app over an insecure connection on a shared network. For the typical self-hosted home use case the practical risk is small.
Technical assessment
The advanced.useSecureCookies option is hard-coded to false rather than conditioned on the scheme of the configured base URL. The accompanying comment explains this is deliberate to keep cookie login working on plain-HTTP LAN deployments, but it also means that when an operator sets an https APP_URL, session cookies are still issued without the Secure attribute, allowing them to be sent over plain HTTP and potentially captured by an attacker positioned on the same network as the user. This is a conditional, network-adjacent weakness in a self-hosted, typically single-user app, not a demonstrated exposure in the supplied evidence.
Impact: low · Exploitability: plausible
Developer action: Consider deriving the Secure cookie flag from the configured APP_URL scheme (enable Secure cookies when the base URL uses https), so secure deployments get browser-enforced cookie protection while plain-HTTP LAN setups keep working.