The merge looked clean. The code compiled. The tests passed. And yet you just leaked an API key to the world.
This is how API security collapses in the quiet moments between git fetch and git push. Most breaches don’t start with ingenious zero-days — they start with sloppy merges, forgotten environment files, and the false sense of safety that comes after a clean git rebase.
When developers rebase a branch, history is rewritten. Commits shift. Secrets accidentally checked in weeks ago can reappear in the new commit tree even after they were “removed.” This is why API key exposure during a git rebase is both common and dangerous. The danger grows when rebased commits flow into CI/CD pipelines without review, automatically deploying credentials into staging or production systems.
The security truth: simply deleting a secret from your repo is not enough. In Git, history is forever unless it’s intentionally rewritten everywhere, including on remotes and clones. A git rebase may resurface sensitive data that had been force-pushed out earlier. Teams that overlook this end up with their API tokens indexed by search engines or harvested by bots scanning public repos.