Service status
Free API Security Check
Check CORS and headers at a public API endpoint
Check a public endpoint
Examine how a publicly reachable HTTP/API endpoint responds to the defined requests. The check looks at CORS, security headers, visible server information and a limited error probe. You receive findings with explanations for your further technical work.
The specified endpoint is checked. The check does not examine logged-in user roles, access rights or business logic and does not replace an API penetration test.
Which responses the check examines
Scope model · not an executed measurement
From the public endpoint to its response
- Public URL including its path
Example:
https://api.example.com/status. Only check authorised targets; do not submit access tokens or confidential data. - Defined GET and OPTIONS requests
For the additional error probe, a test path is appended and retrieved using GET. No PATCH request and no search for all endpoints. The effect of a request also depends on the server implementation.
Where assessable responses can be reached:
On narrow screens, scroll the table sideways.
| Area | What the check can say |
|---|---|
| CORS | Selected CORS headers and responses to the defined requests. |
| Security headers | Security-related headers at the endpoint reached. |
| Error response | The response to the limited additional error probe and any visible error messages. |
| Server information | Server or technology information visible from outside. |
| Rate-limit headers | Visible indications of limits; no measurement of their effectiveness under load. |
| HTTP methods | Visible method information and responses within the described GET/OPTIONS scope. |
A response may come from a gateway, proxy or protective system. Check whether it is meaningful for the intended API function. A blocked or failed request is not a passed check.
Outside the scope: authenticated tests, role and BOLA/IDOR checks, injection test sequences, business logic, endpoint discovery or a separate TLS analysis. CORS does not replace authorisation checks; rate-limit headers are not a load test. “API” identifies the target, not programmatic access to the Wolf scanners.
What you need to check separately
CORS controls, among other things, whether a browser releases a response to a script from another origin. It does not replace server-side authorisation. An appropriate CORS header therefore does not establish that protected data are accessible only to authorised users.
This check does not perform authenticated tests, BOLA/IDOR checks, injection test sequences, business-logic tests or source-code analysis. It also has no separate TLS analysis. A successful HTTPS request alone is not a complete assessment of transport protection.
For a specific CORS issue, also investigate the actual browser flow with its origin, headers and, where relevant, credentials in your own environment. The Wolf check is not a freely configurable debugger for every combination. Test a rate limit using a separate suitable, authorised test; headers do not prove that a limit is enforced.
Understanding the API assessment
A+ is the highest grade in this API check. Its grade sequence is A+, A, A-, B+, B, B-, C+, C, D and F. The API model uses deductions and caps for certain findings. Its assessment does not share a percentage scale with the web or email check.
The grade relates to assessable observations at the time of measurement. If the measurement basis is insufficient, the report may omit an overall grade. “Not measured” must not be read as “passed”. Even A+ proves neither complete API security nor correct access rights behind a login or SSO.
Working with the result
- Choose an authorised public endpoint and start the check.
- Relate the responses obtained to your intended use case. Read findings and measurement gaps together.
- Investigate noteworthy settings in the relevant gateway, server or application code. The check itself does not change your configuration.
- After making a change, request a new check of the same URL if needed. Compare the findings, measurement time and scope of the two results manually.
Keeping the endpoint findings
The PDF, DOCX and CSV files offered on the results page are based on the same scan. PDF is suitable for reading and filing, DOCX for your own additions and CSV for working with the findings table. DOCX is editable; make your own changes recognisable.
Browser findings remain free. Order new report files separately; price, tax and scope appear before you place a binding order. Contract delivery requires an email address. Purchased originals remain in the archive for three calendar years from first delivery. Downloading does not start a new measurement; existing free-file promises retain their original validity.
The optional result-link email is not an additional check and unlocks no further content. The report reading guide shows how to share a finding together with its limits. An automatically calculated comparison report and a personal expert assessment of your endpoint are not included.
Checking an API or using a scanner API?
“API Security Check” here names the target of your check: a public HTTP/API endpoint. Programmatic access to the Wolf-Agents scanners would be a separate service. A public customer API for integrating these scanners is not currently offered here.
To examine a website or a domain’s mail configuration, choose the appropriate route in the checks overview.
Frequently asked questions
Is this a complete API security scanner?
No. A comprehensive API test can also examine permissions, objects, inputs and business logic. This check is limited to selected configuration and response characteristics of a public endpoint.
Does it test BOLA, IDOR or injection?
No. It does not exercise user roles, test protected objects for access by other users or run injection test sequences.
Does the check change data in my API?
It uses GET and OPTIONS, including GET for the additional error path. It does not send PATCH for this purpose. Only check authorised targets: the side effects of a request also depend on the server implementation.
Does a missing rate-limit header prove that no limit exists?
No. The check observes certain response signals and does not run a load test. A limit may be implemented in other ways; equally, a header alone does not prove effective enforcement.
Can I treat A+ as approval to launch?
A+ is the highest grade within this limited scope, not a launch or security approval. Areas outside the scope and measurement gaps remain open. The report does not confirm legal compliance and is not a recognised audit or insurance certificate.
Technical foundations
CORS in the Fetch Standard · HTTP methods: RFC 9110 · How we use AI
The standards explain protocol behaviour. The implemented check is narrower, as described above.