SECTION 01
Solo App Dev Security Starts with Scoping Your Defense
When thinking about security as a solo developer, the first step is choosing where to draw your defense line. You simply cannot protect every surface area alone, so the design decision is about what you own versus what you delegate.
Delaying this decision means you won't be able to respond when something goes wrong after launch. The more accident-prone a domain, the more reason to hand it to a specialized service. This single principle dramatically reduces security burden for indie developers.
In my case, I delegate payments to RevenueCat, a subscription infrastructure service for iOS and Android. Trying to own all the security and compliance around payments leads to operational bottlenecks before code quality even matters. By routing through store submission, closed testing, and real-device payment verification, I cut the risk surface I personally carry.
Authentication follows the same logic — I use Auth.js, a library that standardizes OAuth and session management. Building session handling from scratch is less about the effort and more about the blind spots you'll inevitably miss. Here's how I split responsibilities:
- Own yourself: Core business logic, UI design, data architecture
- Delegate: Payment processing, auth and session management, infrastructure ops
- Decision rule: The higher the blast radius of a breach and the easier it is to get wrong, the more it belongs outside your codebase
Having built over 40 services, I've learned that spending too much time on non-core concerns kills your momentum toward launch. Security is a design problem about what you choose to own — not a quest for perfection across every domain.
SECTION 02
You're a Target the Moment You Ship: Five Holes to Fix First
The moment a web app goes live, it becomes a target for automated scanning and attacks. Bots arrive before humans do. Even with few users, you're exposed. Here are the five vulnerabilities to address first, in priority order.
Number one: hardcoded API keys and secrets leaking into repositories. This is the most common trap for indie developers. When you're deep in development, secret management gets deprioritized, and keys end up in public repos. Leaked keys often remain valid for extended periods, with abuse going undetected until bills spike.
- Manage secrets via .env files and always add them to .gitignore
- Verify no keys exist in your commit history
- Set up a basic secret scanning mechanism
Number two: wildcard CORS settings. It's common to allow all origins during development and forget to tighten it for production. Always explicitly specify allowed origins — this is a one-line fix that closes a real attack vector.
Number three: authentication and authorization gaps. Protecting the login page means nothing if your API endpoints lack proper access control. Define who can access what at every endpoint — this habit prevents the most exploitable class of bugs.
Number four: classic vulnerabilities like SQL injection and XSS. These are old but still devastating. Use your framework's built-in escaping and parameterized queries. Never concatenate user input into query strings manually.
Number five: known vulnerabilities in dependencies. Running npm audit or enabling Dependabot (GitHub's automatic dependency vulnerability scanner) catches known issues automatically.
- Minimum: Run npm audit regularly
- Automate: Enable Dependabot for automatic PRs
- Triage: Fix critical and high immediately; batch low-risk items for maintenance windows
SECTION 03
AI-Generated Code Has Made Solo App Dev Security Harder
Now that AI-powered code generation is mainstream, security blind spots have actually increased. The ease of development means code ships to production with less verification than ever before.
AI-generated code has a structural tendency to include auth gaps and misconfigurations. AI writes code that works, but not necessarily code that works safely. Missing authorization checks on API endpoints or overly permissive default configs are common outputs.
In indie development, the habit of shipping AI-generated code without review creates a compounding security debt. In a team, someone might catch a suspicious config. Solo, that check doesn't exist. Unreviewed code accumulates, and with it, unreviewed vulnerabilities.
Here's how to run security checks at minimal cost:
- Ask AI to review its own output: After generating code, prompt it to identify security issues in what it just wrote
- Use linters with security plugins: ESLint security rules catch common patterns automatically
- Manual pre-launch check: Verify auth, authorization, and input validation by hand — just these three
Don't over-trust AI-generated code. "It works" and "it works safely" are different things. Building a habit of minimal verification between generation and deployment is your defense line as a solo developer.
SECTION 04
Let Your Platform Do the Defending
When I ran MENTA, a mentor-matching service, I managed the servers myself for a period. I know from direct experience what it means to hold infrastructure alone — both the time cost and the mental weight. That's why I now choose to deploy on established platforms.
Owning a server means OS updates, security patches, log monitoring, and incident response all fall on you. For a solo developer, sustaining this is unrealistic. Deploying on platforms like Vercel or Cloudflare offloads these responsibilities structurally.
One pattern I specifically favor is never exposing the server directly to the internet. For HiveCoding, I adopted a Cloudflare Tunnel setup — a mechanism that routes traffic without publicly exposing the server's IP. Just hiding your origin IP significantly shrinks the attack surface.
- WAF (Web Application Firewall): Automatically blocks malicious requests
- DDoS protection: Prevents service outage from traffic floods
- SSL/TLS: Provides HTTPS automatically
Implementing these individually would cost significant time and money, but many are included in Cloudflare and Vercel's free tiers. For indie developers who want protection but lack budget, platform choice solves more than you'd expect.
Infrastructure security isn't about your personal effort — it's about choosing the right platform and getting structural protection by default. Letting go of responsibilities you shouldn't hold solo is the key design decision.
SECTION 05
Holding Less Data Is the Strongest Defense
From a security standpoint, the most effective strategy is not holding data in the first place. The more data you store, the wider your attack surface and the greater the damage if a breach occurs. This is a design philosophy issue, not just a technical one.
I prefer login-free initial experiences in my services. The primary motivation is reducing friction from a UX perspective, but it directly connects to the structural issue: the more user data you hold, the more you have to protect. Starting with a data-minimal structure keeps operational burden low.
Here's a decision framework for whether to store data:
- If you can avoid it, don't store it: Maximize what users can do without logging in
- If you must store it, minimize it: Only save what's genuinely necessary
- If you store it, plan protection first: Design backup, encryption, and access control before writing the first record
"Start simple, add data storage incrementally as needed" works as a decision framework for feature additions too. The moment you add user registration, you're responsible for email security. Add payments, and transaction data needs protection. Each feature expands your security scope.
Avoiding complex state management from the start reduces the points where things can break later. This applies to security and to the sustainability of indie development itself. The less you have to defend, the more you can actually defend alone.
SECTION 06
HTTP Headers and CORS: The Settings Most Solo App Devs Overlook
Security discussions tend to focus on code vulnerabilities, but misconfigured HTTP headers are a blind spot for many indie developers. Browsers offer built-in security features that activate with a single header — leaving them unused is a missed opportunity.
Here are the headers worth setting at minimum:
- Strict-Transport-Security: Forces HTTPS and prevents man-in-the-middle attacks
- X-Content-Type-Options: nosniff: Prevents MIME type confusion
- X-Frame-Options: Blocks clickjacking attacks
- Content-Security-Policy: Restricts which sources can load resources
If you're on Vercel or Cloudflare, these can be added through config files or dashboards with minimal effort. Many frameworks handle some of these automatically, so check once what's already covered in your stack and what needs manual configuration.
For CORS specifically, the pattern of allowing all origins during development and shipping that config to production is alarmingly common. Make it a rule: Access-Control-Allow-Origin: * is for local development only. Always explicitly list allowed origins in production. This single practice closes an entire attack path.
Most header configurations are set-once, zero-maintenance operations. The ongoing cost is effectively zero after initial setup, making them ideal candidates for your pre-launch checklist.
SECTION 07
Dependencies and Supply Chain Risk: Not Just a Big-Company Problem
Indie development relies heavily on npm packages and libraries, but each one is a potential attack vector. Supply chain risk isn't exclusive to enterprises — it applies at every scale, including solo projects.
The habit of treating libraries as unconditionally trustworthy quietly accumulates risk over time. Smaller projects tend to neglect dependency management, and regular scanning rarely happens when you're focused on shipping features.
Set these as your minimum operational rules:
- Run npm audit at least monthly: Prioritize critical and high severity
- Enable Dependabot: One setting on GitHub repos gives you automatic vulnerability PRs
- Regularly remove unused packages: Dead dependencies expand your attack surface for no benefit
You don't need to fix every vulnerability immediately. Prioritize critical issues and batch lower-risk ones into maintenance cycles. The goal isn't perfection — it's ensuring no critical holes stay open.
Dependency security is something you can set up once and let run automatically. A small upfront investment in configuration pays off with near-zero ongoing operational cost.
SECTION 08
Secret Management Basics: Protecting What Can't Be Unleaked
API keys, database connection strings, external service tokens — when these secrets leak, the damage spreads immediately. For indie developers, secret management is the most fundamental defense line in security.
The actions are simple, but easy to deprioritize when you're focused on building:
- Use environment variables: Never hardcode secrets. Manage them via .env files
- Add .env to .gitignore: Prevent repository contamination
- Use separate keys for production and development: A leaked dev key shouldn't compromise production
If keys have already entered your commit history, adding .gitignore alone won't remove them from the log. The safest response is to immediately invalidate the key and issue a new one. Operating under the assumption of compromise is more reliable than trying to clean history.
Platforms like Vercel and Cloudflare provide secure dashboards for managing environment variables. Use these for production secrets, keeping them separate from your local .env files.
Getting secret management right prevents the majority of security incidents in indie development. It's unglamorous but delivers the highest return on investment of any security practice.
SECTION 09
When Things Go Wrong: First Response Moves for Solo Developers
Security incidents are a question of "when," not "if." How fast you move in the first minutes determines the scale of damage. As a solo developer, having a pre-planned response matters even more than it does for teams.
If an API key is compromised, here's the immediate sequence:
- Invalidate the key immediately: Don't wait to assess impact — stop the bleeding first
- Issue a new key and update environment variables: Prioritize service restoration
- Check access logs: Look for signs of unauthorized usage
If user data may be affected, you need to determine scope and notify users. What data may have been exposed? Over what time period? What should users do in response? Organize these answers and communicate honestly — transparency is the best way to preserve trust.
The worst response to an incident is "it's probably fine" followed by inaction. Automated bot attacks don't discriminate by project size. If something seems off, err on the side of overreacting rather than under-reacting.
One thing worth doing in advance: document the key invalidation process for every service you use. Searching for admin panels while panicking leads to poor decisions. Check the procedures while you're calm, and keep them somewhere instantly accessible.
SECTION 10
A Security Operations Checklist You Can Actually Run Solo
Here's everything above consolidated into a pre-launch and post-launch checklist. You don't need to execute everything perfectly, but the items at the top of each list are non-negotiable.
Pre-launch verification:
- Secrets managed via environment variables with .env in .gitignore
- CORS allowed origins explicitly configured (no wildcards)
- All pages served over HTTPS
- Security-related HTTP headers configured
- Auth and authorization verified per API endpoint
- npm audit shows no critical vulnerabilities
Ongoing post-launch tasks:
- Dependency updates (at least monthly)
- Access log anomaly checks (roughly weekly)
- API key rotation (per service recommendations)
- Dependabot alert response (critical items same-day)
The key to this checklist is separating one-time setups from recurring tasks. Most pre-launch items are configure-once. Post-launch items can be largely automated through Dependabot and CI/CD, minimizing what you actually do by hand.
Indie dev security isn't about achieving perfection — it's about closing the holes that would be fatal. Narrow your scope, delegate to specialized services where appropriate, and focus your attention on the points that truly matter. With this design philosophy, a solo developer can absolutely maintain an adequate defense line.
