What is the API Security Scanner?
The API Security Scanner is a continuous monitoring product that runs weekly passive security checks against your REST API endpoints. It probes for the most common and impactful API vulnerabilities from the OWASP API Security Top 10 (2023) and produces a scored report with findings, severity ratings, and remediation guidance.
This is a separate product from the OpenAPI/Swagger Import feature in the vulnerability scanner. The API Security Scanner monitors a live API endpoint on a recurring schedule and alerts you when new issues are found.
What is checked
HTTPS enforcement (OWASP API8)
The scanner checks whether the API base URL serves over HTTPS and whether plain HTTP requests are redirected. APIs served over HTTP expose all traffic — authentication tokens, request bodies, response data — to interception.
Security headers (OWASP API8)
The scanner checks for the presence of security headers in API responses. While not all headers apply to pure APIs, the following are checked:
| Header | Risk if missing |
|---|---|
X-Content-Type-Options: nosniff | Responses may be MIME-sniffed, enabling content injection |
X-Frame-Options | API documentation or embedded views can be framed for clickjacking |
Strict-Transport-Security | Clients may connect over HTTP on subsequent requests |
CORS misconfiguration (OWASP API8)
Cross-Origin Resource Sharing (CORS) misconfigurations are one of the most common API security issues. The scanner checks for:
- Wildcard with credentials —
Access-Control-Allow-Origin: *combined withAccess-Control-Allow-Credentials: trueis invalid per the spec but some browsers accept it - Origin reflection with credentials — the API mirrors the request's
Originheader back and allows credentials, letting any website make authenticated cross-origin requests - Wildcard without credentials — allows any website to read the API response, which may be acceptable for public APIs but is flagged for review on authenticated endpoints
Authentication bypass indicators (OWASP API2 / API5)
The scanner probes discovered endpoints without any authentication credentials. If an endpoint returns a non-error response (2xx or 3xx) to an unauthenticated request, it is flagged as a potential broken authentication or broken function level authorization finding for manual review.
Sensitive data in responses (OWASP API3)
The scanner inspects API response bodies for patterns indicating that responses contain more data than the client should receive — email addresses, phone numbers, internal IDs, private keys, and similar fields that suggest excessive data exposure.
Verbose error messages (OWASP API9)
The scanner sends malformed requests and checks whether error responses contain SQL error text, stack traces, framework internals, or server version strings. Verbose errors give attackers detailed information about the technology stack and query structure.
Dangerous HTTP methods (OWASP API8)
The scanner checks whether the API accepts the TRACE method, which can be used in Cross-Site Tracing (XST) attacks to read HTTP-only cookies and authorization headers.
Rate limiting (OWASP API4)
The scanner sends 12 rapid POST requests to an authentication-style endpoint and checks whether the API responds with HTTP 429. Absence of rate limiting enables brute-force attacks against login endpoints and credential stuffing at scale.
JWT weaknesses (OWASP API2)
When a JWT token is found in an API response or provided via your auth header configuration, the scanner checks:
- Algorithm: none — whether the API accepts tokens signed with the
alg: nonevulnerability - Weak secret — whether the token can be verified with a common weak secret (e.g.
secret,password)
Endpoint discovery
The scanner discovers API endpoints in two ways:
- OpenAPI / Swagger schema — if you provide an OpenAPI schema URL (or the scanner auto-detects it at common paths like
/openapi.json,/swagger.json,/api/docs), all defined endpoints are imported and checked individually. - Common path probing — the scanner probes a curated set of common API paths (
/api/v1,/api/users,/api/health, etc.) and adds any that return a non-404 response to the endpoint list.
/openapi.json, /swagger.json, or /api/v1/openapi.json on your API.Scoring
Each scan produces a security score from 0 to 100. Findings deduct points based on severity:
| Severity | Deduction | Example findings |
|---|---|---|
| CRITICAL | −30 | Auth bypass on sensitive endpoint, JWT alg:none accepted |
| HIGH | −15 | CORS origin reflection with credentials, no rate limiting on auth |
| MEDIUM | −8 | Wildcard CORS, verbose error messages, HTTP TRACE allowed |
| LOW | −3 | Missing security headers, weak JWT secret |
| INFO | −1 | API served over HTTP (redirects to HTTPS) |
The score is capped at a minimum of 0. A score of 90+ indicates a well-configured API; below 60 indicates significant issues that should be remediated before a security audit or penetration test.
Plans and quotas
| Plan | API endpoints | Scan frequency | OpenAPI import | Email alerts |
|---|---|---|---|---|
| API Starter | 3 | Weekly | Yes | Yes |
| API Pro | 10 | Weekly | Yes | Yes |
Adding an API endpoint
Open the API Security tab in the dashboard. Click Add API endpoint and fill in:
| Field | Description |
|---|---|
| API base URL | The root URL of your API — e.g. https://api.example.com/v1 |
| Label (optional) | A friendly name shown in the dashboard |
| OpenAPI URL (optional) | URL of your OpenAPI / Swagger schema for endpoint discovery |
| Auth header (optional) | A full Authorization: Bearer <token> header value, stored encrypted, used to test authenticated endpoints |
Alert emails
You receive an email alert when:
- A new CRITICAL or HIGH severity finding is detected that was not present in the previous scan
- A previously clean scan now has findings
- The scan encounters an error reaching the API endpoint
Triggering a manual scan
Click Scan now on any API endpoint card to run an immediate scan. Use this after deploying API changes, rotating auth configuration, or adding rate limiting to verify the fix is detected.
Scan history
Click View history on an endpoint card to see a timeline of all past scans, scores, and finding counts. Select any scan to review the full findings list and the endpoints that were discovered at that point in time.
Frequently asked questions
Will the scanner create or modify data in my API?
No. The scanner is strictly passive. It sends read requests to endpoints, probes for error indicators with benign payloads, and inspects responses. No POST/PUT/DELETE requests that would create or modify real data are sent, and no authentication credentials are captured or reused beyond the auth header you provide.
What is the difference between this and the OpenAPI/Swagger import in the vulnerability scanner?
The OpenAPI/Swagger Import in the vulnerability scanner uses your API schema to guide a one-shot security scan of your API as part of a broader OWASP Top 10 assessment. The API Security Scanner is a monitoring product — it runs automatically on a weekly schedule, tracks changes over time, and alerts you when new issues appear. Use both: schema import for deep one-shot assessments, API Security Scanner for continuous monitoring.
My API requires client certificates or IP allowlisting — will the scanner work?
Client certificate authentication and IP allowlisting will prevent the scanner from reaching the API. For IP-allowlisted APIs, you can add the Shieldome scanner IP to your allowlist and contact support for the current egress IP range. Client certificate authentication is not currently supported.
What if my API is on a private network?
The scanner runs from Shieldome's infrastructure and can only reach publicly accessible endpoints. For private APIs, consider the self-hosted option or use the one-shot scanner with the OpenAPI import feature from within your network.
How are auth headers stored?
Auth header values are stored encrypted at rest. They are only decrypted at scan time and are never included in scan reports or alert emails. Use a dedicated scanner token with minimal permissions.