APIs are the hidden attack surface of modern web apps. Here's how to find exposed endpoints, test for common vulnerabilities, and fix what you find — without spending a dime.
You built a web app. It has a frontend that users see, and an API that powers it. You secured the frontend. The API? That's where the real action happens — data going back and forth, authentication tokens, business logic, database queries. And it's probably exposed to the internet in ways your frontend never was.
API vulnerabilities are consistently among the most critical risks in modern web applications. The OWASP API Security Top 10 lists broken object-level authorization, broken authentication, and excessive data exposure as the most common API-specific issues. Most of them are testable with free tools. Here's how.
Before you can test an API, you need to know what endpoints exist. A modern web app might expose dozens of API endpoints that aren't visible in the navigation — they're used by the frontend JavaScript to communicate with the server.
Open your browser's developer tools, go to the Network tab, filter for XHR/fetch requests, and browse your site. Capture all the API calls. Also check your JS files directly — any file at /js/*.js probably has API endpoint references. Look for fetch(, axios., $.ajax, and URL patterns like /api/, /v1/, /rest/.
If your app uses a standard API structure, you might have a documentation endpoint at /api-docs, /swagger.json, /openapi.json, or /api/v1/api-docs. OpenAPI documentation is machine-readable — you can feed it directly into testing tools to automate security tests.
API versions get deprecated but stay live. Check archive.org's Wayback Machine for old versions of your JavaScript files or documentation pages — they often reference API endpoints that are no longer documented but still functional.
This is the most common and most dangerous API vulnerability. The problem: you log in as User A, and the API lets you access User B's data by changing an ID parameter. Test it: authenticate as one user, find an API call that returns user-specific data (like /api/users/123/profile), and try changing the ID to someone else's. If you get their data without authorization, you have BOLA. This is exploitable in most APIs that don't enforce strict authorization checks per resource.
APIs are supposed to return what's needed. But many return full objects and rely on the frontend to filter what it displays. This means an attacker can directly call the API and see fields that the UI never shows — SSN, internal IDs, metadata. Test: call each endpoint and examine the full response, not just what the frontend displays. Look for fields that shouldn't be there.
JWT tokens, API keys, session tokens — if any of these are implemented incorrectly, authentication fails. Common mistakes: tokens signed with weak keys, tokens that don't expire, tokens that can be reused after logout, API keys that are guessable or enumerable. Test JWT tokens with the jwt_tool Python script — it checks for algorithm confusion, weak keys, missing expiration, and more.
API responses often include more fields than the frontend uses. But some of those fields might be settable by the client — like is_admin: false. If the API accepts client-supplied field values without validation, an attacker can modify fields they shouldn't be able to. Test: examine API responses for interesting fields (role, status, admin, created_at), then try submitting those fields with new values in a POST/PUT request.
Automated scanners find known patterns. Manual testing finds business logic flaws — the vulnerabilities that are specific to how YOUR API works.
APIs get exploited because nobody's watching them. Most of the vulnerabilities are fixable with proper access control and input validation — the problem is that teams don't test for these issues until after a breach. Don't wait for that.
APIs get exploited because nobody's watching them.
Scan Your API Endpoints →