GitHub Pages Workflow Exposes Unmerged Development Code to Public Internet

A misconfigured GitHub Actions workflow in the InfraLens project publicly serves the `dev` branch alongside production code. The Pages deployment workflow checks out both `main` and `dev`, copying development work directly into the public artifact served at `https://floriancasse.github.io/InfraLens/dev/`. This means unmerged commits, prototype features, half-fixed vulnerabilities, and work-in-progress code execute in users' browsers without any access controls or version negotiation.

The affected workflow file `.github/workflows/pages.yml` explicitly concatenates both branches into a single deployment artifact. Lines 25-32 and 38 instruct the runner to checkout `main` into the root directory and `dev` into a `/dev/` subdirectory, then serve both simultaneously. Security researchers note this creates a persistent attack surface where fixes applied to `main` may remain exploitable through the `dev/` mirror. Additionally, incident response becomes complicated when vulnerability reports reference paths that are not part of the production release cycle.

The exposure raises several concerns: attackers can analyze unmerged development code for credentials, API keys, or architectural details not yet hardened for production. Proof-of-concept exploits targeting vulnerabilities patched on `main` may retain effectiveness against the `dev` endpoint. The configuration also violates standard security practice of maintaining strict separation between internal development artifacts and public deployments. Organizations using similar multi-branch Pages workflows should verify that only intended branches enter production artifacts.