Shipping fast feels great—until the hackers show up.

Leo Jr. learned this the hard way. He’s a non-technical indie hacker who built and scaled an app publicly, attracting attention (and revenue) with spicy takes like "AI SaaS won’t work." But the attention didn’t stop at engagement. It made him a target.

Soon after, hackers began probing his app for security flaws. And they found plenty—API keys exposed in the codebase, easily bypassable paywalls, and more. The result? Half the internet was trying to break his app for fun.

This isn’t new. Pieter Levels, Marc Lou—other big names in the indie hacker world have dealt with DDoS attacks and vulnerability exploits after their products blew up. But Leo’s case stands out because he’s not a developer. He vibe-coded his way to success without fully understanding the security side of things.

What Indie Hackers Can Learn

As someone who's also building and shipping apps fast (and not immune to these risks), here are two key takeaways:

1. Hide Your API Keys

Publicly exposed API keys are an open invitation to hackers. Store them securely using environment variables instead of hardcoding them in your codebase. If you’re using Next.js, create a .env.local file and reference the keys like this:

NEXT_PUBLIC_API_KEY=your-key-here

Then access it in your code like this:

const apiKey = process.env.NEXT_PUBLIC_API_KEY;

Simple fix, big impact.

2. Stop Using CSS for Paywalls

CSS-based paywalls (display: none;) are laughably easy to bypass. Instead of relying on front-end styling, enforce the paywall logic on the backend. If that's too complex, a middle-ground solution is to obfuscate the content using Base64 encoding and set up DevTools protection to make it harder to bypass.

3. Securing Webhooks – The Overlooked Weak Spot

Webhooks are essential for automating tasks between apps—but they’re also an easy target for attackers if left unprotected. Here’s how to lock them down:

• Use a Signature and Timestamp – Your webhook’s receiving URL must be public, but you can secure the data using a signature, timestamp, and token to create a hashmap (a key-value store).
• Generate a HMAC Signature – Link the timestamp and token values, encode them using the HMAC algorithm with your ESP’s API key (in SHA256 mode), and compare the result with the signature.
• Reject Duplicate Tokens – Cache the token value locally and reject any request that tries to reuse the same token. This prevents replay attacks where hackers repeat or misdirect the webhook action.

Here’s a quick example in TypeScript for securing webhooks:

import crypto from 'crypto';

const verifyWebhook = (signature: string, timestamp: string, token: string, secret: string) => {  
  const data = `${timestamp}.${token}`;  
  const expectedSignature = crypto  
    .createHmac('sha256', secret)  
    .update(data)  
    .digest('hex');  

  return signature === expectedSignature;  
};

Shipping Fast ≠ Ignoring Security

As an indie maker, I get it—speed matters. But security matters too. Leo’s experience is a reminder that even if you're not a developer, securing your app isn’t optional. Don’t let vibe coding turn into vibe hacking.

I’d love to hear from other makers—how are you balancing speed with security in your builds?

Let’s discuss in the comments.