Challenge 3: Find the Security Mistake — Possible Solution
====================================================================

This one line stacks THREE separate mistakes, each bad enough on its
own:

1. HARDCODED CREDENTIAL IN SOURCE CODE. The username and password are
   written directly into application code instead of being loaded from
   an environment variable or secrets manager. Anyone who can read the
   source — including every future developer, every CI job, anyone who
   clones the repo — can read the raw password.

2. COMMITTED TO GIT. Once pushed, this credential is compromised
   FOREVER, per the CI/CD Pipelines course's core rule — even if the
   line is deleted in a later commit, the password remains readable in
   the repository's history indefinitely, unless the entire history is
   rewritten AND every existing clone is somehow invalidated (in
   practice, treat it as unrecoverable — the only real fix is rotating
   the credential itself).

3. OVER-PRIVILEGED ACCOUNT. The username is literally "admin" against
   a PRODUCTION cluster — almost certainly a broad or root-equivalent
   role, not a scoped readWrite user for just the shop database. If
   this credential leaks, the blast radius is the entire cluster, not
   one application's data.

THE FIX:
  - Immediately rotate the credential (change the password / recreate
    the user) — assume it is already compromised, per point 2.
  - Replace the hardcoded string with an environment variable read:
    const uri = process.env.MONGODB_URI;
  - Create a properly scoped user (e.g. readWrite on shop only, per
    Challenge 2's pattern) instead of using an admin-level account for
    routine application connections.
  - Add the credential to .gitignore-covered configuration (e.g. a
    .env file that is itself never committed) and, ideally, a
    secret-scanning tool in CI to catch this class of mistake before
    it reaches a commit at all.