fix: remove hardcoded JWT secret defaults from config files (CWE-798)

[saaa99999999]

Summary

Three config files contain hardcoded or weak JWT secret defaults that allow token forgery:

1. .env.example:67 — JWT_SECRET_KEY="Change me!" — a weak placeholder
2. docker-compose.yml:51 — JWT_SECRET_KEY=${JWT_SECRET_KEY:-fgr4fe34w2rfTwfe3444234edfewfw4e#f$#wferg23w2DFSdf} — hardcoded string visible in public repo
3. docker-compose.loadbalanced.yml:98 — JWT_SECRET_KEY=${JWT_SECRET_KEY:-Change me!} — same weak placeholder

The application uses jsonwebtoken::encode() and jsonwebtoken::decode() with EncodingKey::from_secret() / DecodingKey::from_secret() via HS256 (symmetric). Anyone who reads the repo can forge valid JWT tokens and authenticate as any user.

Data Flow

1. .env.example:67 → docker-compose.yml:51 — Secret flows from env file to container
2. src/utils/auth.rs:26-27 — SECRET_KEY loaded via lazy_static! from get_env("JWT_SECRET_KEY") (panics if missing)
3. src/utils/auth.rs:103-107 — Token signing:

   encode(&Header::default(), &claim, &EncodingKey::from_secret(SECRET_KEY.as_ref()))

4. src/utils/auth.rs:115-136 — Token verification:

   decode::<Claims>(&jwt, &DecodingKey::from_secret(secret_key.as_ref()), &validation)

The get_env("JWT_SECRET_KEY") function already panics at startup if the env var is missing — this is good. But the docker-compose defaults silently supply a hardcoded key, preventing the panic from triggering.

Fix

.env.example:66-69

Before:

# JWT secret key.
JWT_SECRET_KEY="Change me!"

After:

# JWT secret key — REQUIRED. Generate a strong key with:
#   openssl rand -base64 32
# The application will refuse to start if this is not set.
JWT_SECRET_KEY=

docker-compose.yml:51

Before:

- JWT_SECRET_KEY=${JWT_SECRET_KEY:-fgr4fe34w2rfTwfe3444234edfewfw4e#f$#wferg23w2DFSdf}

After:

- JWT_SECRET_KEY=${JWT_SECRET_KEY:?required — generate with: openssl rand -base64 32}

docker-compose.loadbalanced.yml:98

Same Docker Compose fix — ${JWT_SECRET_KEY:-Change me!} → ${JWT_SECRET_KEY:?required ...}

The ${VAR:?message} syntax causes Docker Compose to fail with a clear error message if the variable is not set, rather than silently falling back to a hardcoded value. Combined with the existing get_env() panic in the application code, this provides defense in depth: Docker Compose catches the missing variable before the container even starts.

Impact

• CWE-798: Use of Hard-coded Credentials
• CVSS 3.1: 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N)
• Two hardcoded keys were in the public repo. "Change me!" is a weak placeholder that a developer might not change. fgr4fe34w2rfTwfe... is a pseudo-random string but is compromised because it is public.

[saaa99999999]

CVE Request — Action Needed from Maintainer

This PR fixes security vulnerabilities. To assign a CVE number:

GitHub only issues CVEs from the official upstream repository, not from forks.

Please:

1. Go to this repo → Security → Advisories → New draft security advisory
2. Add @saaa99999999 as a collaborator
3. I will populate the full vulnerability details (CVSS, CWE, data flow, PoC) and submit the CVE request

If you prefer, I can submit the CVE via MITRE (cveform.mitre.org) instead — just let me know.

Thank you for reviewing this PR!

[Riktastic]

Hi there thank you for creating this pull request! Haven't been able to reply sooner.
No sure if this repository is worth the trouble of creating a CVE. The issue is rather small and it really needs to be updated to more recent versions of the used libraries.

What do you recommend me to do, to at least handle this in a respectful way.

[saaa99999999]

Thanks for the kind reply, and no worries about the delay.

Regarding the CVE question — honestly, for a 42-star repo, the fix itself matters more than the CVE. The PR removes the hardcoded JWT keys so anyone deploying this won't be vulnerable to token forgery. That's the important part.

If you do want a CVE, the process is simple: merge the PR, then go to Security → Advisories → New draft, add @saaa99999999 as collaborator, and I fill in the rest. But there's no requirement to do this. The fix already protects users.

A middle ground: merge the PR, and I can submit the CVE directly via MITRE on my end so you don't have to deal with the GitHub advisory process. Either way works.

As for updating the dependencies — that's orthogonal to the security fix. The JWT key issue is independent of library versions. You can do that separately whenever it makes sense.