API Security for Startups — The Vulnerabilities No One Is Testing
API Security for Startups — The Vulnerabilities No One Is Testing
TLDR: API vulnerabilities were a factor in over a third of web application breaches in 2024, according to the Akamai State of the Internet Security Report. Most startups test their frontend and call it done. Attackers go straight for the API — because that's where the data actually lives, and that's where the controls are most consistently missing. This post covers the six most common API vulnerabilities I find in real assessments, how to check for them yourself, and the quick wins you can implement this week.
Why APIs Are the New Attack Surface
Modern web applications don't work the way they used to. Ten years ago, a web app was a server rendering HTML and returning pages. Today, it's a React or Vue frontend talking to a REST or GraphQL API, which talks to microservices, which talk to third-party integrations. The API is the application. The frontend is a display layer.
This architecture change has created a security blind spot that affects the vast majority of early-stage startups. Teams invest in frontend hardening — input sanitisation on forms, CSP headers, WAF rules — while the API layer that actually serves and accepts sensitive data gets tested incompletely or not at all.
The OWASP API Security Top 10 — published specifically because API vulnerabilities were distinct enough from web application vulnerabilities to warrant their own list — documents the attack patterns being exploited actively against production APIs worldwide. The list isn't theoretical. Every item on it appears regularly in real assessments and real breach post-mortems.
The 6 Most Common API Vulnerabilities I Find
1. No Authentication or Weak Authentication on Endpoints
The most straightforward finding — and more common than you'd expect in production systems. An endpoint that should require a valid session token works fine without one. Sometimes it's a legacy endpoint left over from development. Sometimes it's a "read-only" endpoint where the developer assumed read access wasn't sensitive. Sometimes it's an oversight during a refactor.
Attackers don't assume. They enumerate every endpoint systematically. GET /api/users, GET /api/admin/stats, GET /api/export — if any of these respond with data to an unauthenticated request, the authentication on your login page is irrelevant.
2. Excessive Data Return
Your API returns a full user object. Your frontend displays three fields. The other twenty fields — including password hashes, internal flags, admin booleans, private notes, and fields your developers used for debugging — are sitting in the API response, invisible in the UI but fully accessible in the browser developer tools or through a direct request.
This is one of the most common findings in API assessments and one of the easiest to miss during development, because the frontend works correctly. The data leakage is only visible when you look at the raw API response — which developers rarely do after the frontend is built.
3. No Rate Limiting on Sensitive Endpoints
A login endpoint with no rate limiting accepts unlimited authentication attempts. An attacker with a list of email addresses and a password wordlist can run automated credential stuffing indefinitely — trying thousands of combinations per minute, harvesting every account with a weak or reused password.
The same applies to password reset endpoints, OTP verification, and any endpoint that accepts sensitive input. Without rate limiting, every one of these is a brute-force target. The fix — IP-based and account-based rate limiting with lockout logic — is well-documented and straightforward to implement in any major framework.
4. Broken Object-Level Authorization (API-Level IDOR)
We covered IDOR in our previous post in the context of URL parameters. At the API level, the same pattern appears in request bodies and headers — {"document_id": 5512}, {"user_id": 2047}. The application processes the request without verifying whether the authenticated user actually owns the referenced object.
In API-first architectures this is particularly widespread because API endpoints are often built quickly to serve frontend needs, and the ownership check is assumed to be handled elsewhere — by the frontend, by the router, by a middleware that may or may not actually be applied.
5. API Keys Embedded in Frontend JavaScript
Open your browser developer tools on a typical SaaS product. View Source. Search for api_key, secret, token, Authorization. You'll find them in a depressing percentage of applications — credentials for third-party services like SendGrid, Stripe, Twilio, or internal services, hardcoded into JavaScript that ships to every browser that visits the page.
Frontend JavaScript is public. Everything in it is readable by anyone. An API key in your frontend bundle is an API key that belongs to the internet. Attackers scrape these routinely — tools exist specifically for this purpose. The consequences range from unexpected billing charges to full account takeover of the exposed service.
6. Verbose Error Messages Revealing Internal Structure
Error: SequelizeDatabaseError: relation "internal_users_v2" does not exist at line 47 of /app/services/authService.js
This error, returned by a production API to an anonymous user, tells an attacker your ORM, your internal table naming conventions, your file structure, and the exact line where the logic lives. It's a map. The fix is a single environment configuration change that routes verbose errors to logs and returns generic messages externally.
How to Test Your Own API
You don't need specialist tools to do a basic API security review. Two tools cover most of what you need at the exploratory stage.
Postman (free tier is sufficient) lets you send arbitrary API requests, modify headers, remove authentication tokens, and change request parameters — all without touching the frontend. Work through your own API with your session token, then systematically remove or alter the token and see what still responds. Test every endpoint with a second account's credentials accessing the first account's objects.
Burp Suite Community Edition (free) acts as a proxy between your browser and your application, capturing every API request in real time. Use your application normally while Burp captures the traffic, then replay and modify requests from its interface. This makes it straightforward to spot excessive data return in responses and to test for missing authorisation checks.
The manual process is time-intensive but instructive. Most teams who go through it methodically discover at least one significant finding they weren't aware of.
What a Proper API Security Assessment Involves
A professional assessment goes beyond manually testing the endpoints you know about. It includes:
Endpoint discovery — mapping the full API surface, including undocumented or legacy endpoints not visible in the frontend. Automated tools combined with manual enumeration regularly surface endpoints developers have forgotten exist.
Authentication and authorisation testing across all endpoint types — GET, POST, PUT, DELETE, PATCH — with multiple account privilege levels. Many applications correctly protect write endpoints but leave read endpoints open.
Business logic review — testing multi-step flows, parameter manipulation, and the assumptions encoded in the API's design that may not survive contact with a motivated attacker.
Response analysis — reviewing every endpoint's response for fields that shouldn't be returned, internal identifiers that could be used for enumeration, and error messages that leak structure.
Quick Wins You Can Implement Today
If you're not in a position to run a full assessment immediately, these four changes measurably reduce your API exposure:
Audit authentication on every endpoint. Open your router file. For every endpoint, confirm an authentication middleware is explicitly applied. Don't assume inherited authentication — verify it.
Add rate limiting to login, password reset, and OTP endpoints. Libraries exist for every major framework. This is a two-hour implementation that eliminates credential stuffing as a viable attack.
Review your API response objects. For each endpoint, confirm the response contains only what the client actually needs. Strip internal fields, debug fields, and anything not explicitly required by the frontend.
Search your frontend JavaScript for credentials. Before your next deployment, run grep -r "api_key\|secret\|token\|password" ./src against your frontend codebase. Move anything that surfaces into environment variables on the server side.
Find What Your Scanner Missed
Automated scanners do not find most of these vulnerabilities. They can't reason about business logic, can't compare what the frontend displays against what the API returns, and can't enumerate undocumented endpoints the way a human tester can.
If your product is live, handles customer data, or is approaching an enterprise sales cycle, a dedicated API security assessment is the most efficient way to understand your actual exposure — not your theoretical exposure, but what a real attacker targeting your specific API would find.
Explore our services or get in touch to discuss what an assessment would cover for your stack. For more on how we approach security testing, visit our about page.
More technical security guides for developers and founders are available on the Kuboid Secure Layer blog.
