I used to think that security was something only big enterprises needed to worry about. "Who's going to hack my little side project?" I'd tell myself. "I'm just building a simple SaaS for 10 users."
Then I saw a post on Reddit from a developer whose indie project got hit by a botnet. The attacker found a single unprotected API endpoint, exploited a simple IDOR (Insecure Direct Object Reference) vulnerability, and wiped his entire database.
That’s the thing about the internet: nobody cares how small you are. Automated scanners run 24/7, looking for open S3 buckets, exposed .env files, and missing authentication headers. If your app is public, you are a target.
I spent the next few weeks learning about web security. I didn't want to become a security expert — I just wanted to ensure my side projects weren't an easy target.
Here is the exact checklist I now use before deploying any side project to production.
- Authentication & Authorization The most common bug in side projects is confusing authentication with authorization.
Authentication: Who are you?
Authorization: Are you allowed to see this?
I cannot tell you how many times I've seen an API endpoint like GET /api/user/123 where 123 is just the user ID. If you change 123 to 124, you can see another user's data. This is called IDOR.
The Fix: Never trust the client. If a user requests /api/invoices/123, your backend must verify that the authenticated user actually owns invoice 123. Use UUIDs instead of sequential IDs to make it harder for attackers to guess.
- The .env File (The Silent Killer) As developers, we love open-source. But we often push our .env files to public GitHub repositories by accident. If your database credentials, API keys, or JWT secrets are exposed, your app is essentially a public frontend.
The Fix:
Add .env to your .gitignore file (do this immediately).
Use a tool like git-secrets or GitHub's secret scanning to prevent committing keys by accident.
Rotate your keys if you suspect they've been leaked. Don't just delete the commit — the data is already out there.
- Rate Limiting (Why You Need It) If you have an API, you need rate limiting. Without it, a bot can brute-force your login page or spam your signup form, causing resource exhaustion or spamming your database.
The Fix: Use a middleware like express-rate-limit for Node.js, or use a service like Cloudflare or Upstash to rate limit requests at the edge. A simple rule like "100 requests per 15 minutes per IP" will stop 99% of automated abuse.
- Password Hygiene If you're building an app, you're likely dealing with passwords. If you're storing passwords in plain text, stop what you're doing and fix it immediately.
The Fix: Use a strong hashing algorithm like bcrypt or argon2. Never write your own cryptography.
But the real security win comes from the user side. If you run any kind of SaaS, consider implementing 2FA (Two-Factor Authentication). It’s the single most effective way to prevent account takeovers.
I’ve actually built a Password Playbook that documents the exact steps for securing accounts in 30 minutes—it's great to share with your users or keep for yourself.
- Never Trust User Input SQL Injection (SQLi) and Cross-Site Scripting (XSS) are still two of the most common vulnerabilities in web apps. If you're using an ORM like Prisma or Drizzle, most of these attacks are mitigated. But if you're writing raw SQL, you must use parameterized queries.
The Fix:
Sanitize and validate all incoming data using a library like zod or joi.
Use parameterized queries.
Set up a strict Content Security Policy (CSP) to prevent XSS.
The Pre-Deploy Checklist
Before you run npm run build and push to production, run through this checklist:
Authentication: Are all endpoints protected?
Authorization: Does every route verify ownership (IDOR)?
Input Validation: Is every request body validated with a schema?
Secrets: Is .env in .gitignore? Are there any hardcoded API keys?
Rate Limiting: Are your routes protected against spam?
Passwords: Are they hashed with bcrypt?
If you want the exact technical checklist I use for my own side projects, I’ve compiled it into an API Security Checklist. It walks through every endpoint, header, and token.
Stay safe out there.
Have you ever been hacked? What’s the biggest security mistake you’ve made in a side project? Let’s share our war stories in the comments!
Top comments (1)
I remember the first time I left my .env file in a public repo. It was a tiny project, but the panic when I got an email from GitHub about leaked keys was real. What's the most common security mistake you see in side projects?