How to Scan Your Production API for Vulnerabilities (Step-by-Step Guide)

Most API security problems aren't in the code — they're in the configuration. Missing headers. Overpermissive CORS. Endpoints that respond to unauthenticated requests. These issues are invisible to static analysis tools and unit tests because they only appear when your API is actually running in production, handling real HTTP traffic.

The only way to find them is to scan your live API from the outside — the same perspective an attacker has. This guide walks through exactly how to do that, step by step.

For background on why external scanning is a different discipline from code analysis, read this overview of external security scanning.

What You're Looking For

A production API vulnerability scan is looking for things that are wrong in the deployed state of your application — not in your source code. The main categories:

• Missing security headers — Content-Security-Policy, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. These control browser behavior and prevent a range of client-side attacks.
• Overpermissive CORS — APIs that return Access-Control-Allow-Origin: *on authenticated endpoints, or that reflect arbitrary origins without validation.
• Exposed endpoints — Routes that respond with data or accept mutations without requiring authentication. Debug routes, admin endpoints, and health checks that return sensitive system information.
• TLS/SSL issues — Expired certificates, weak cipher suites, missing HSTS headers, or HTTP-to-HTTPS redirect failures.
• Response data leakage — API responses that include sensitive fields (internal IDs, stack traces, environment names, database details) that should be stripped before returning to clients.
• Missing rate limiting — Authentication endpoints that accept unlimited requests, enabling credential stuffing and brute force attacks.

Step 1: Run an External Scan

The fastest way to get an external perspective on your production API is to run an automated external scan. You're looking for a tool that sends real HTTP requests to your live endpoints — not one that analyzes your source code.

Go to scantient.com/score and enter your API's base URL. The scanner will make external requests to your endpoints, analyze the responses, and produce a scored report covering:

• Security header presence and configuration
• CORS policy analysis
• TLS certificate status and strength
• Accessible endpoint discovery
• Response data field analysis

The whole process takes under 60 seconds. No signup. No SDK or agent to install — the scanner operates entirely from the network, seeing exactly what an external attacker would see.

Step 2: Review the Security Headers Report

Once your scan completes, start with the security headers section. This is typically where most APIs have the most findings — and most are fixable in under 30 minutes.

For each failing header, the fix is usually adding a line to your server configuration or Next.js headers() function. Common examples:

• Missing HSTS: Add Strict-Transport-Security: max-age=31536000; includeSubDomains. This tells browsers to only connect via HTTPS for the next year.
• Missing X-Content-Type-Options: Add X-Content-Type-Options: nosniff. Prevents browsers from MIME-sniffing responses.
• Missing X-Frame-Options: Add X-Frame-Options: DENY to prevent your app from being embedded in iframes (clickjacking protection).
• Missing CSP: Content-Security-Policy is more complex — start with a restrictive policy and loosen as needed. Even a basic default-src 'self'is better than nothing.

After fixing headers, redeploy and rescan. Header issues should resolve completely within one deploy cycle.

Step 3: Audit Your CORS Configuration

CORS (Cross-Origin Resource Sharing) findings need more careful attention because the right fix depends on your API's intended consumers.

Red flags to look for:

• Access-Control-Allow-Origin: * on endpoints that handle authenticated requests or return user data. Wildcards should never appear on authenticated routes.
• APIs that reflect the Origin request header directly back inAccess-Control-Allow-Origin without validation — this effectively allows any origin.
• Missing Vary: Origin header when CORS responses vary by origin — this can cause cache poisoning.

Fix: explicitly whitelist the origins your API should accept. In Express: cors({ origin: ['https://yourapp.com'] }). Never use a wildcard on authenticated routes.

Step 4: Investigate Exposed Endpoints

The exposed endpoints section shows routes that responded to the scanner's unauthenticated requests. Review each one and ask: should this be publicly accessible?

Common findings:

• /api/health or /healthz — These are expected to be public. But check what they return — some health endpoints expose version numbers, environment names, database connection status, or dependency versions. Trim the response to just {"status": "ok"}.
• Admin or internal routes — If /api/admin/* or/api/internal/* responds to unauthenticated requests, this is a critical finding. Add authentication middleware immediately.
• Debug or development routes — Routes added during development and never removed. Common examples: /api/debug,/api/test, /api/seed. Delete them.

Step 5: Check TLS Configuration

TLS issues are often overlooked because "the padlock is green" in the browser. But there's more to TLS security than certificate validity:

• Certificate expiry — Set up automated renewal (Let's Encrypt certbot, or your platform's managed certificates). An expired cert breaks your app for all users.
• HTTP to HTTPS redirect — Ensure requests to http://redirect to https:// with a 301 or 308 response. Not a 200.
• HSTS preloading — For high-value APIs, submit your domain to the HSTS preload list so browsers never make an insecure connection, even for first visits.

Step 6: Review the Security Score and Prioritize

Your scan produces a score reflecting overall API security posture. Use it as a baseline — not a final grade. The goal isn't a perfect number; it's tracking meaningful improvement over time.

Prioritization framework:

1. Fix critical findings first — Unauthenticated access to admin endpoints, wildcard CORS on authenticated routes, expired TLS certificates.
2. Fix header findings next — These are low effort, high impact, and often require only a configuration change.
3. Schedule data leakage remediation — Stripping sensitive fields from API responses may require code changes and testing.
4. Set up continuous scanning — A one-time scan is better than nothing, but continuous external monitoring catches new vulnerabilities introduced with each deploy.

What External Scanning Doesn't Cover

An external API scan is powerful but not omniscient. It won't find:

• Business logic vulnerabilities (these require understanding your app's intent)
• SQL injection or injection flaws in specific query parameters
• Authentication bypass flaws in your login flow
• Vulnerabilities in your frontend JavaScript

External scanning catches the configuration-layer vulnerabilities. Code-level vulnerabilities require a combination of SAST tools, dependency scanning, and manual review. Both perspectives are necessary — they don't overlap, they complement each other.

Making Scanning a Habit

The most valuable thing you can do after your first scan is make it a recurring practice. Your API changes with every deploy — new endpoints, updated dependencies, modified configurations. A scan that was green last month may have new findings today.

With Scantient's LTD plan, you get continuous external monitoring — scans run automatically and you get notified when new findings appear. It's the difference between a security snapshot and a security posture.