Locking Down the API Endpoints Anyone Can Call

Your demo worked. The product did exactly what you promised, the investor nodded, and the pilot customer asked about onboarding. What you did not show—and what vibe-coding tools never told you—is that every endpoint the demo called is still reachable by anyone with a browser and a URL. The question is not whether to fix that. The question is how to do it without stalling the momentum you just earned.

Situation: You shipped an AI-generated MVP and it works. Complication: The tools that built it were designed to make things run, not to refuse unknown callers—so open access is the starting condition, not a mistake you made. Question: What does it actually take to lock those endpoints down before a pilot customer, a due-diligence reviewer, or a curious stranger finds them open? Answer: A structured three-step process—map, restrict, verify—closes that exposure without rebuilding what you already have.

Why can anyone call my API right now?

Vibe-coding tools generate working route handlers by default. "Working" means the endpoint responds to a request—not that it checks who is sending it. Because the tools optimise for a successful demo response, they produce no authentication guard unless you explicitly prompted for one, which almost no one does on the first pass.

The mechanism is straightforward: when an AI code generator writes a route, it satisfies the prompt—"create an endpoint that returns user data"—completely. Adding a middleware layer that rejects callers without a valid token is a separate concern, and the tool does not volunteer it. The result is a route file full of handlers that answer every caller equally, authenticated or not. That is not a flaw in your thinking; it is the default output of tools built to demo well.

What does an exposed endpoint actually do to my pilot?

An unauthenticated endpoint lets any caller—not just your pilot users—read, write, or delete real data. In a pre-revenue product that is collecting even basic user information, that exposure can trigger compliance obligations, erode pilot trust the moment it surfaces, and hand a technical reviewer an immediate reason to pause a deal.

The business consequence is specific. A pilot customer who discovers their data is reachable without credentials does not frame it as a technical oversight—they frame it as a question of whether you are ready to be trusted with production use. An investor's technical reviewer running even a casual audit will enumerate your routes; an open endpoint on a data-sensitive path is a findings item that delays term sheets. Neither outcome requires a breach. The exposure alone is enough.

How do I find which endpoints are open before someone else does?

The prerequisite step is a mapping pass: enumerate every route in your application, label its authentication state as guarded or unguarded, and categorise it by data sensitivity. That gives you a concrete list instead of a vague anxiety about unknown exposure—and it tells you exactly where the remediation effort needs to land.

Start in your route file. List every path—GET, POST, PUT, DELETE—alongside the handler it calls. For each one, note whether any middleware runs before the handler executes. If the answer is no middleware, mark it open. Then assign a sensitivity tier: does this route touch user records, payment references, or credentials? Does it return internal identifiers? Does it allow writes? A route that returns a public product list and a route that returns a user's account details are both open by default, but they carry different risk weights. The mapping separates them so you fix in the right order.

What am I actually looking for in the code?

Three signals appear consistently in vibe-coded route files, and each one is a distinct category of risk. Routes with no middleware guard before the handler—the most common pattern—mean any caller reaches the logic. Hard-coded credentials or tokens inside a handler mean a secret is visible to anyone who can read the response or the source. Endpoints that return more data fields than the caller needs mean an over-permissive response is leaking structure the caller was never supposed to see.

Each signal requires a different fix. No middleware guard is solved by adding one. Hard-coded secrets require rotation and environment-variable replacement. Over-permissive responses require a response-shaping step that filters the output to only what the caller's role should receive. Treating all three as the same problem—"just tighten security"—misses the fact that they operate at different layers of the stack.

What does locking down an endpoint actually involve?

Remediation follows a three-part sequence: add authentication middleware, enforce least-privilege responses, rotate any exposed secrets. Each step operates independently, which means you can work through them in priority order without stalling other development.

Adding authentication middleware means inserting a function that runs before your handler and validates the caller's token or session. If the token is absent or invalid, the middleware returns a rejection—typically a 401—and the handler never executes. The handler itself does not change. Your business logic, your data queries, your response formatting all stay exactly as they were. The middleware sits in front of them and controls access.

Enforcing least-privilege responses means the endpoint returns only the fields the caller's role is permitted to see. If a route returns a full user object but the caller only needs a display name and an account tier, the response shape narrows to those two fields. Rotating exposed secrets means generating new credentials for anything hard-coded, storing the new values in environment variables, and invalidating the old values at the source—the database, the third-party service, wherever the credential was issued.

Do I have to rebuild anything, or can the existing code be salvaged?

The remediation approach is refactor-first. Authentication middleware wraps existing handlers—it does not replace them. Your core product behaviour, the speed you shipped at, and the features your pilot agreed to test are all preserved. The security layer is added on top of what already works, not substituted for it.

This distinction matters because the alternative framing—that a vibe-coded codebase is too compromised to salvage—leads founders to pause products that do not need to be paused. The business logic your AI tools generated is often sound. The gap is not in what the code does when a legitimate user calls it; the gap is in what it does when an illegitimate caller tries. Closing that gap is a wrapping operation, not a rewrite. Three days of targeted refactoring—adding middleware, tightening responses, rotating secrets—is a realistic scope for a single-path remediation on a typical MVP route file. No rebuild.

How do I know the fix actually worked?

Verification is a deliberate test pass, separate from the fix itself. For each endpoint you remediated, call it without valid credentials and confirm the response is a rejection. A 401 or 403 returned consistently across every formerly-open route is an objective signal. An assumption that the middleware is working is not.

The test pass has a specific shape: use a tool or a script that can send raw HTTP requests without a session cookie or bearer token attached. Call the endpoint. Read the status code. If the status is anything other than an authentication rejection—if you receive a 200, a 204, or any data payload—the guard is not in place. Log the result for each route against your map from the initial enumeration. When every open route on your map returns a rejection on an unauthenticated call, the pass is complete and you have a dated record of the outcome. That record is what you show a pilot customer or a technical reviewer who asks whether the exposure has been addressed. It converts "we fixed it" from a claim into evidence.

The route from open-by-default to verified-and-restricted does not require starting over. It requires a map, a structured remediation sequence, and a test pass you can point to. Your AI-generated MVP got you to a demo that worked—the next step is making it one that also says no to callers who were never supposed to reach it.