The Uncomfortable Truth
You are one person against every script kiddie and bot on the internet. Here is how to not lose.
Let me be clear about something. Nobody is specifically targeting you. You are not important enough for a targeted attack. (No offense.) The threat is automated. Bots crawl the entire internet looking for easy wins. They do not care who you are. They care that your .env file is publicly accessible.
The good news: most automated attacks are dumb. They look for the same 50 things on every site. If you fix those 50 things, you are fine. The bad news: most indie hackers have not fixed them.
The Attacks That Actually Hit Indie Hackers
Your .env file is on the internet
This is number one for a reason. Bots crawl every domain they find and check for /.env, /.env.local, /.env.production. If your environment file is accessible, an attacker now has your database password, your Stripe secret key, your email API key and anything else you put in there.
Fix: Visit yourdomain.com/.env right now. If you see anything other than a 404, you have a problem. Fix it immediately. Configure your web server to block access to dotfiles. On Nginx, add location ~ /\. { deny all; } to your config.
Credential stuffing on your login
An attacker takes a list of emails and passwords from some other breach (there are billions of these floating around) and tries them all on your login form. If any of your users reused a password, the attacker is in.
Fix: Rate limit your login endpoint. 10 attempts per minute per IP is a good start. Add CAPTCHA after 3 failed attempts. Encourage (or require) strong passwords. MFA is even better, but rate limiting is the minimum.
Broken authorization (the big one)
Your app checks if someone is logged in. But does it check if they should see the specific data they are requesting? Can User A access User B's invoices by changing the ID in the URL from /invoice/123 to /invoice/124?
This is the most common vulnerability we find in indie hacker apps. Every. Single. Time.
Fix: On every API endpoint that returns user-specific data, check that the logged-in user owns that data. Not just "is logged in" but "is this their data." If your query looks like SELECT * FROM invoices WHERE id = ?, it should look like SELECT * FROM invoices WHERE id = ? AND user_id = ?.
Dependency hijacking
You installed a package from npm six months ago. The maintainer's account got compromised. An attacker pushed a malicious update. Your next deploy pulled the compromised version. Now there is a cryptominer running on your server.
Sound unlikely? It happens constantly. The event-stream incident affected millions of downloads. Smaller packages get compromised every week.
Fix: Pin your dependency versions. Use lock files (package-lock.json, Pipfile.lock). Run npm audit weekly. Review what you are installing before you install it. If a package has 12 downloads and was last updated three years ago, maybe do not use it.
DNS takeover
You set up a CNAME record for docs.yourapp.com pointing to a service you used to use. You canceled the service. You forgot to delete the DNS record. An attacker claims that subdomain on the service and now controls docs.yourapp.com.
They can host a phishing page there, set cookies for your domain or collect credentials from users who think they are on your legitimate site.
Fix: Audit your DNS records every few months. Delete any CNAME or A records that point to services you no longer use. This takes five minutes and prevents a genuinely nasty attack.
Your git repo is public (and has secrets in it)
Bots scrape GitHub 24/7 looking for API keys, database credentials and tokens. If you ever committed a secret to your repo, even if you deleted it later, it is still in your git history. Forever.
Fix: Search your git history for secrets: git log -p | grep -i "sk_live\|password\|secret\|api_key". If you find anything, rotate those credentials immediately. The secret is compromised. Do not just delete it from the repo. Assume it has been found. Use gitleaks as a pre-commit hook to prevent future accidents.
The 30-Minute Security Sprint
You do not have time for a two-week security audit. I get it. Here is what you can do in 30 minutes that eliminates the most common attack vectors.
Minutes 1-5: Check if your .env file is accessible from the internet. Fix it if it is.
Minutes 5-10: Enable MFA on your hosting, database, DNS and payment accounts. All of them.
Minutes 10-15: Run npm audit (or your language's equivalent). Fix critical findings.
Minutes 15-20: Add rate limiting to your login endpoint if you do not have it.
Minutes 20-25: Check your DNS records. Delete anything pointing to services you do not use.
Minutes 25-30: Search your git history for secrets. Rotate anything you find.
Done. You just eliminated the attack vectors that account for roughly 60% of the indie hacker breaches we respond to.
The Stuff You Cannot Do Yourself
The 30-minute sprint covers the automated attacks. But there is a whole category of vulnerabilities that require a human to find.
Business logic flaws. Payment flow manipulation. Session hijacking. Privilege escalation. Authorization bypasses across complex workflows. These are the vulnerabilities that actually ruin businesses, and no amount of self-auditing or automated scanning will catch them.
That is what a Quick Audit is for. $1,500 CAD. A human security professional spends a week trying to break your app. They test every endpoint, every flow, every edge case. You get a plain English report with exactly what to fix.
Think of it this way. You built the house. You installed the locks. Now you are paying someone to try to break in before the real burglars do.
The Real Talk
Most indie hackers will not get hacked. Most apps are not interesting enough to attract targeted attacks. But "most" is not "all," and automated bots do not discriminate.
The ones who do get hacked share a common trait: they assumed it would not happen to them.
Run the free hack tool. Do the checklist. Fix the obvious stuff. And when you have revenue, get the audit.
You are building something from nothing. That takes guts. Do not let a preventable breach take it away.