API Security for Vibe-Coded Apps: Protecting Your Endpoints

Every vibe-coded app with dynamic data has API routes. They're the bridge between your frontend and your database — and they're almost always the weakest link. Here's a systematic approach to securing them.

Why API Security Matters Most

Your frontend is just a suggestion. Anyone can bypass it and call your API directly with curl, Postman, or a script. Every security measure on the frontend (disabled buttons, hidden fields, client-side validation) is cosmetic. The real security happens at the API layer.

Step 1: Inventory Your Routes

Before securing anything, know what you have. Use this prompt:

"List every API route in this application in a table with columns: HTTP method, path, what it does, whether it requires authentication, and whether it modifies data. Include routes created by frameworks or libraries."

This gives you a map. Every route that reads user data needs authentication. Every route that modifies data needs authentication AND authorization.

Step 2: Add Authentication Guards

The most common vulnerability in vibe-coded apps: API routes with no authentication. AI builds the route, makes it work, and moves on. It doesn't add the auth check because you didn't ask.

The Prompt

"Add authentication middleware to this application. Create a helper function called requireAuth that checks for a valid session and returns the authenticated user. If no session exists, return 401 Unauthorized JSON. Apply this to every API route except: public listing endpoints, health checks, and authentication endpoints themselves."

Step 3: Validate Every Input

Never trust data from the client. Even if your frontend sends clean data, an attacker will send whatever they want.

What to Validate

The Prompt

"Add input validation to every API route that accepts data. Use Zod (or the validation library already in this project) to define schemas for request bodies. Validate at the start of each handler. Return 400 with specific field-level error messages for invalid input. Add maximum string lengths to prevent abuse."

Step 4: Implement Rate Limiting

Without rate limiting, an attacker can:

Tiered Rate Limits

Different endpoints need different limits:

The Prompt

"Add rate limiting with these tiers: public read routes at 120 requests per minute per IP, authenticated write routes at 30 per minute per user, authentication routes at 5 per minute per IP. Use an in-memory store for development and Redis for production. Return 429 Too Many Requests with a Retry-After header and a JSON error message."

Step 5: Prevent Data Leakage

API responses often include more data than the frontend needs. AI grabs all columns from the database and sends them to the client.

Common Leaks

The Prompt

"Audit every API response in this application. Create a whitelist of fields for each resource type that should be included in API responses. Strip all other fields before sending. Specifically ensure: password hashes are never returned, email addresses are only visible to the account owner, internal database IDs are replaced with public slugs or UUIDs where possible, and admin fields are only included for admin users."

Step 6: Handle Errors Safely

In development, detailed error messages are helpful. In production, they're information leaks.

Bad

Error responses that include: stack traces, file paths, database query details, environment variable names, or internal IP addresses.

Good

Generic error messages like "Something went wrong" with a reference ID the user can share with support, and detailed logging on the server side.

The Prompt

"Add global error handling to all API routes. In production mode: return generic error messages with a unique error reference ID, log the full error details server-side, never include stack traces or file paths in responses. In development mode: return full error details for debugging."

Step 7: Protect Against Common Attacks

SQL Injection

If you're using an ORM (Prisma, Drizzle, TypeORM), you're mostly safe — but check for raw queries.

Cross-Site Request Forgery (CSRF)

If your auth uses cookies (most apps do), state-changing requests need CSRF tokens.

Mass Assignment

If AI passes the entire request body to the database, attackers can set fields they shouldn't — like isAdmin or planType.

The Prompt

"Check for these vulnerabilities: 1) Any raw SQL queries that concatenate user input — replace with parameterized queries. 2) State-changing endpoints without CSRF protection — add CSRF tokens. 3) Database creates or updates that accept the full request body — whitelist only the specific fields that users should be able to set."

Your API Security Checklist

Use this as a quick reference before deployment:

Submit your app to VibbleLaunch after implementing these fixes. Our security scanner evaluates your headers, and the Security Leaderboard rewards apps that take protection seriously.