The flagged line just reads the app's own configured web address from settings and uses it to set up the login system correctly. Nothing sensitive is copied out or sent anywhere.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.serialize-environment. The match applies to this repository.
Contextual assessment: The serialize-environment signal at line 9 corresponds to reading an environment variable (APP_URL) and combining it with a localhost fallback literal. The resulting value is used only as the auth library's baseURL and as a trusted-origin entry in this server-side authentication configuration. No environment data is serialized into client-shipped output, exfiltrated to a remote destination, or written to logs. Reading a deployment URL from configuration is standard and proportionate for a self-hosted app whose README instructs users to set APP_URL for production.
The scanner flagged the app's default local web addresses. These are just the normal placeholders used when running the app on your own machine, not suspicious external sites.
Technical evidence
Scanner reason: JavaScript analysis matched static JavaScript security signal javascript.xray.shady-link. The match applies to this repository.
Contextual assessment: The shady-link signal on line 9 reflects the plain-HTTP localhost fallback literal (and the related localhost origin on line 17). These are development and local-network defaults for a self-hosted application, used solely as the authentication base URL and trusted origins. No request is made to these addresses at scan time; they are configuration defaults, not network callbacks or data exfiltration destinations.
Session cookies deliberately allowed over plain HTTP
low risk · high confidence
The app lets you stay logged in even when running on a network without encryption. That's a deliberate convenience choice; if someone runs it over an untrusted network without HTTPS, a snooper on that network could theoretically see the login cookie. For typical home or localhost use this is not a practical problem.
Technical assessment
The configuration disables the Secure cookie flag so login sessions work on plain-HTTP LAN or reverse-proxy deployments without TLS. The code comments show this is an intentional, documented trade-off rather than a mistake. On a plain-HTTP network, a network-level observer could read the session cookie, but this is a deployment-transport risk the operator chooses by running without TLS, and the project's threat model is self-hosted local use. No attacker-controlled path is demonstrated by the supplied evidence.
Impact: low · Exploitability: unlikely
Developer action: Consider gating the Secure-cookie setting on whether the configured base URL uses HTTPS, or documenting that users exposing the app over a network should put TLS in front of it.