Security

Findings (this standalone repo)

F-1: Hardcoded fallback session secret (low)

In server.js:

secret: process.env.SESSION_SECRET || "change-me",

If SESSION_SECRET is not set, the literal string "change-me" becomes the cookie-signing secret. The session middleware is currently unused by the handlers (nothing reads or writes req.session), so the practical impact is low. But: if a future handler starts using sessions, this fallback will silently allow trivially-forgeable cookies in deployments that forgot to set the secret.

Fix: throw at startup if SESSION_SECRET is unset. Or remove express-session entirely if no handler uses it.

F-2: Auth-by-convention (medium)

In production mode, handlers read res.userId and res.accountId as if they're always set — but the auth that sets them lives in the parent someli-api and is mounted before the dashboard router. If the dashboard router is ever mounted in a context where that upstream auth is absent (for example, if someone extracts this repo into a standalone service per Path B in relationship-to-someli-api.md), the handlers will run with userId === undefined and accountId === undefined.

In SQL terms, this would result in queries like:

WHERE accountId = ?  -- bound to undefined → likely an error or empty result

which would fail safely (no data returned) — but the behaviour isn't intentional.

Fix: add an in-router guard:

router.use((req, res, next) => {
  if (!res.userId || !res.accountId) {
    return res.status(401).json({ status: false, message: 'unauthenticated' });
  }
  next();
});

This is defensive but cheap.

F-3: Mock auth would be deployable (low-likelihood, high-impact if it happens)

In local-dev mode, mock/middlewares/auth.js sets fake userId / accountId and never validates anything. If this repo is ever accidentally deployed with NODE_ENV=development, every request would succeed as a fake user with hardcoded privileges.

Fix: in addition to whatever orchestration prevents misconfiguring NODE_ENV in prod, add a defensive guard:

if (isLocal && process.env.ALLOW_MOCK_AUTH !== 'yes') {
  throw new Error('Mock auth disabled. Set ALLOW_MOCK_AUTH=yes if intended.');
}

F-4: Inherited security posture of sibling repos

Because the production copy lives inside someli-api, it inherits everything in ../someli-api/security.md — JWT in encrypted token header, apptype base64 header, sync MySQL with parameterised queries (mostly — see the SQL injection risks documented in someli-api/security.md), CORS wildcard, etc. Re-reading that doc is recommended.

F-5: Spurious dependencies

The package.json declares jsonwebtoken, crypto-js, request, node-cron, path — none of which are require'd by any file in this repo. Each is an unnecessary attack surface, especially request (officially deprecated since 2020) and path (the npm path package is a third-party clone of a built-in module, last published in 2015).

Fix: prune unused dependencies — npm uninstall jsonwebtoken crypto-js request node-cron path.

What's not a finding here

• SQL injection — the con.query(...) calls in routes/index.js use parameterised arguments (the second arg is an array). They are mostly safe. A spot-check at line ~38 confirms con.query(\… WHERE accountId = ? AND ...`, [selaccountId])`. Spot-check the additions for the same property.
• XSS / SSRF — no user input is rendered or forwarded to external systems by this repo.
• CSRF — endpoints are all GET; no state-changing operations.
• CSP / X-Frame-Options — not this repo's concern (responses are JSON, not HTML).