Security Tip: Selectively Stage and Commit Changes

[Tip#10] You should always selectively stage changes, to avoid committing secrets or debug code and pushing to prod.

Three months! It’s hard to believe we’ve been going for three months now, but the dates don’t lie. Thanks to everyone for your support and encouragement, and I hope you stick around for many more!

For our In Depth next week, I’m planning on diving into the recently fixed Blade vulnerability, using it as a case study of how placeholders, and other generated tokens, can pose a security risk if they can be guessed or manipulated. But for now, we’re covering a security tip that focuses on your developer workflow.

For the free subscribers, please consider upgrading to a paid subscription. You’ll get these security tips weekly, and our monthly In Depth emails. Last month we dived into Escaping Output Safely through Blade, and featured hands-on XSS exercises.

---

Selectively Stage and Commit Changes

When committing changes into version control, you should always selectively stage your changes first before committing. This allows you to manually review every line of code you commit, to ensure any secrets

¹

or debug code isn’t added.

This is super easy in Git:

git add -p

You can also selectively stage specific files:

git add -p <file>

I’ve even taken it a step further with some Git aliases:

git addp  =>  git add -p
git addc  =>  git add -p && git commit -v
git acp   =>  git add -p && git commit -v && git push

Sometimes the changes are massive and take time to review, but if you’ve ever accidently pushed debug code onto prod

²

, you’ll appreciate the time saved cleaning up that mess!

1. API keys, passwords, etc… see Tip#3: App Config.

2. Like Stack Overflow, with alert(false);