7 API Security Mistakes Killing Your Startup
You shipped fast. That's the point. But these seven mistakes are sitting in your production API right now — and any one of them is enough to lose a customer, fail a compliance audit, or end up on HackerNews for the wrong reason.
Most security breaches don't happen because a genius attacker found a zero-day. They happen because someone left the door unlocked. For APIs, "leaving the door unlocked" looks like a missing header, a hardcoded key, or a CORS policy that says "yes" to everyone.
Here are the seven API security mistakes we see most often when running an api vulnerability scanner against real startup apps — plus what to do about each one.
1. Exposing API Keys in Client-Side JavaScript
What it looks like: You're building a React or Next.js app. You need to call Stripe, OpenAI, or Supabase from the frontend. So you set NEXT_PUBLIC_STRIPE_SECRET_KEY in your environment and it works. You ship.
What actually happened: Every user who opens DevTools → Network → any API call can now read your Stripe secret key. In a real incident Scantient found during a beta scan, a founder had left $50K worth of live Stripe credentials in their JavaScript bundle — publicly readable, no auth required.
What to do instead: Secret keys stay on the server. Use server-side API routes (Next.js API routes, Express endpoints) to proxy calls that require secret credentials. NEXT_PUBLIC_ variables are for client-safe config only: analytics IDs, public Stripe publishable keys, feature flags.
How Scantient catches it: We scan your JavaScript bundles and API responses for patterns matching 20+ known API key formats (OpenAI, Stripe, Supabase, AWS, Twilio, SendGrid, and more). If a key is visible in client-side code, we flag it immediately.
2. Missing Security Headers (Your App Is Basically Open)
What it looks like: Your app works perfectly. Users love it. But there's no Content-Security-Policy, no X-Frame-Options, no Strict-Transport-Security. These headers aren't visible to users — they're invisible until something goes wrong.
What actually happened: Without CSP, an attacker who finds an XSS vector can run any script they want in your users' browsers — steal session cookies, redirect to phishing pages, exfiltrate data. Without X-Frame-Options, your app can be embedded in an iframe on any site for clickjacking attacks. Without HSTS, users connecting over HTTP aren't automatically upgraded to HTTPS.
What to do instead: Add these headers to your server response. In Next.js, add them to next.config.js under headers(). In Express, use the helmet middleware. At minimum: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
How Scantient catches it: Every scan checks for the presence and correct configuration of all five critical security headers. Missing or misconfigured headers are flagged with severity ratings and specific fix instructions.
3. Overpermissive CORS (You Just Opened Your API to Everyone)
What it looks like: You're getting CORS errors during development. The fastest fix is Access-Control-Allow-Origin: *. It works. You ship it to production.
What actually happened: Any website in the world can now make authenticated requests to your API using your users' session cookies. A malicious site can read your users' private data, make purchases on their behalf, or extract their account information — all without them knowing.
What to do instead: Lock CORS to specific origins: Access-Control-Allow-Origin: https://yourapp.com. In development you can allow localhost; in production it should be an explicit allowlist. Never use * in combination with credentials: true.
How Scantient catches it: We probe your API endpoints and check CORS response headers. Wildcard policies and overpermissive configurations are flagged as high-severity findings.
4. Leaving Debug Endpoints Exposed in Production
What it looks like: During development, you added /api/debug, /admin/test, or you deployed to a platform that automatically exposes server status endpoints. Maybe your AI coding assistant (Cursor, Copilot) added a health check route that dumps environment variables.
What actually happened: Attackers probe for common paths within minutes of finding a new app. Endpoints like /.env, /.git/HEAD, /api/admin, /phpinfo.php, Spring Boot actuators — these are checked automatically by every basic vulnerability scanner. If yours respond with 200, that data is exposed.
What to do instead: Return 404 (not 403) for sensitive paths. Review every route your AI assistant added. Remove debug endpoints before deploying. Consider a WAF rule to block probes for these paths.
How Scantient catches it: We test 15 common dangerous paths on every free scan — the same paths any attacker checks first. If they respond, you'll know before the attacker does.
5. No Auth Check on Server-Side Routes (Frontend-Only Auth)
What it looks like: Your dashboard checks if the user is logged in and hides the admin section if not. But the underlying /api/users endpoint? It returns all users to anyone who calls it directly — because the auth check is only in the React component.
What actually happened: Authentication that only exists on the frontend is not authentication. Any developer with Postman (or even just curl) can bypass your UI entirely and hit your APIs directly. This is how competitor data scraping, account takeovers, and data breaches happen at startups that "definitely had auth."
What to do instead: Every API route that returns user-specific or sensitive data must verify a valid session token server-side before processing the request. Never trust the frontend to enforce authorization.
How Scantient catches it: We detect auth patterns that appear to be frontend-only — hardcoded role checks in JavaScript bundles, API routes that accept requests without any auth headers, and public endpoints returning data that looks user-specific.
6. SSL Certificate Expiry (Your Site Goes Down, You Find Out from a Customer)
What it looks like: Everything is fine — until it isn't. Your SSL certificate expires. Your site shows a security warning to every visitor. Conversion drops to zero. You find out from a Slack message at 6 AM: "Hey, your site says it's not secure?"
What actually happened: SSL certificates expire. It's not a security attack — it's an operational failure. But the result is the same: 100% of users see a browser warning and most will leave. For B2B SaaS, this is potentially fatal to a sales cycle.
What to do instead: Use Let's Encrypt with auto-renewal (most platforms handle this). Set calendar reminders 30, 14, and 7 days before expiry for any cert you manage manually. Monitor it automatically.
How Scantient catches it: Every scan checks your SSL certificate validity and expiry date. You'll get alerts at 30, 14, and 7 days before expiry — long before it becomes a crisis.
7. Skipping the Startup Security Checklist Before Launch
What it looks like: You built something great. You shipped. You told users about it. But you didn't run a single security check before launch — because security felt like an enterprise problem, something to worry about after you get traction.
What actually happened: The average cost of a data breach for a small business is $120,000 (IBM 2024). Most startups don't survive one. And the uncomfortable truth: breaches happen at companies with no users, too — because attackers scrape new domains from DNS logs, certificate transparency logs, and product launches. You're being probed within hours of going live.
What to do instead: Run a security audit before launch. It doesn't have to be expensive or time-consuming. A 60-second external scan catches the most common critical issues — the ones that make attackers say "this one is easy."
How Scantient catches it: One free scan covers all seven of these mistake categories. No signup, no SDK, no setup. Paste your URL, get your security score, and know exactly what to fix before your first real user hits your app.
The Startup Security Checklist
Before you launch (or right now, for apps already live):
- ✅ No secret keys in client-side JavaScript or environment variables prefixed
NEXT_PUBLIC_ - ✅ Security headers: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
- ✅ CORS locked to specific origins, never
*with credentials - ✅ No debug/admin endpoints exposed publicly
- ✅ All API routes verify auth server-side, never trust frontend-only checks
- ✅ SSL certificate monitored with alerts before expiry
- ✅ Run an external security scan before launch
The difference between a startup that survives its first security incident and one that doesn't isn't luck — it's whether they ran the checklist.
If you want to know how your app stacks up against enterprise security tools like Snyk without the enterprise price tag, Scantient's lifetime deal is $79 — less than a month of most security tools, with no recurring fees.
Find out which of these mistakes are in your app right now
Run a free scan now. 60 seconds. No signup. No SDK. Just paste your URL.