• Zero IQ
  • Posts
  • Ship Code, Not Regrets: 5 Security Rules Every Dev Must Follow

Ship Code, Not Regrets: 5 Security Rules Every Dev Must Follow

The 5 dumbest ways smart developers leak user data—and how to avoid them.

Author

Ayush Pawar
March 23, 2025

You’ve finally shipped your side project. Everything works. Users are signing up. Life is good.

Then a random person on the internet sends you this:

“Hey, your database credentials are in the repo.”

— Anonymous, probably saving you from public shame

Don’t be that dev.

Security isn’t rocket science. Most of the time, it’s just common sense in disguise. So here are 5 security habits that’ll save you from sleepless nights, data breaches, and awkward “we take security seriously” tweets.

1. 🎯 Move All Your Credentials into a .env File

Hardcoding secrets in your codebase is like tweeting your home address and saying, “I trust the community.”

Use a .env file. Always. 

DB_URL=postgres://your_very_sensitive_data
JWT_SECRET=top_secret_key
STRIPE_API_KEY=shh_don't_tell

Most frameworks (Node, Python, etc.) support loading env variables using libraries like dotenv. No excuses.

👊 Pro-tip: Also load different .env files for different environments (.env.local, .env.prod, .env.dev). Keeps things clean.

2. 🚫 Add .env to Your .gitignore

Moving secrets to .env is step one. Step two? Don’t commit them to Git like a clown.

Add this to .gitignore: 

.env
.env.*

That’s it. Done. Never worry again about accidentally publishing your secrets to GitHub.

🔍 Bonus Tip: Set up git-secrets to scan commits for secrets before you push. It’s like having a personal bouncer for your repo.

3. 🍪 Don't Send JWT & Refresh Tokens in Headers

Look, sending tokens in headers works. But here’s the problem:

  • They’re accessible via JavaScript (XSS nightmare)

  • They don’t work well with browsers + CSRF protection is tricky

Instead, use HTTP-only cookies:

  • Safer (not accessible via JS)

  • Better integration with frontend frameworks

  • Automatically handled by browsers 

// Set token in cookie
res.cookie('token', jwtToken, {
  httpOnly: true,
  secure: true,
  sameSite: 'Strict'
});

🧠 Rule of thumb: If it’s a browser app, use cookies. If it’s an API client (e.g., Postman), headers are fine.

4. 🔐 Add Row-Level Security (RLS) to Every Table

Let’s say you’ve built a multi-user app. Users can log in, create posts, check stats. Everything looks great… until one user can access another’s data.

Oops.

This happens when you forget Row-Level Security (RLS).

What’s RLS? It’s like bouncers at a nightclub—only the right people get in.

In Postgres (or Supabase): 

CREATE POLICY "Users can access their own data"
  ON users
  FOR SELECT
  USING (auth.uid() = id);

🚨 If you’re using Supabase or Hasura and not enabling RLS—you’re asking for trouble. RLS is not optional. It’s essential.

5. 🧱 Rate Limit Your Endpoints

Bots are not cute when they’re hammering your login endpoint 1000 times a second. Rate limit everything—especially:

  • Login

  • Signup

  • OTP/Password reset

  • Anything public

If you're using Express: 

const rateLimit = require('express-rate-limit');
const limiter = rateLimit({
  windowMs: 60 * 1000, // 1 minute
  max: 10 // limit each IP to 10 requests per minute
});
app.use('/api/login', limiter);

Or go big brain and use Cloudflare, Vercel, or an API gateway with built-in limits.

💡 Want to look fancy? Implement exponential backoff for repeated requests.

🏁 Conclusion: Secure Is the New Smart

You don’t need to become a security expert.
You just need to avoid being stupid in obvious places.

Most breaches don’t happen because of genius hackers—they happen because someone left the door wide open.

So:

  • Store secrets properly

  • Keep them out of Git

  • Use cookies, not headers

  • Enforce access control

  • Limit the spam

Do these five, and you're already 90% ahead of devs who "don’t have time for security."

Still ignoring this? Cool.
I look forward to reading your “we take your security seriously” tweet.