A model-serving endpoint is an API, so the OWASP API risks apply in full. It adds a few extra concerns: control and metrics routes that may sit outside authentication, cost abuse through long requests, shared cache or tenant leakage, and internal cluster ports that assume a trusted network.
What stays the same
Broken object level authorization, broken authentication, and unrestricted resource consumption lead the OWASP API Security Top 10 for 2023, and all of them apply to a model endpoint. Server side request forgery and improper inventory management are on that list too. If you would test it on a normal API, test it here.
What is different
The vLLM project's own security guide is a good example of the extra surface. It says its API key covers only certain path prefixes, and that several other endpoints, including metrics, tokenization, scoring, and some operational controls, are not covered by that key. It recommends a reverse proxy that allowlists the routes you intend to expose. It also says multi node traffic is insecure by default and should sit on an isolated network.
Ray's security documentation takes a similar position: security and isolation must be enforced outside the cluster, and anyone who can reach the dashboard or job endpoints can run code on it.
| Concern | Normal API | Model endpoint |
|---|---|---|
| Authentication scope | Usually uniform across routes | May cover only some path prefixes |
| Cost abuse | Rate limits by request | Also limit tokens, context length, and concurrency |
| Tenant separation | Row level checks | Also caches, adapters, and shared instances |
| Internal traffic | Often service mesh | Cluster ports may be unauthenticated |
| Input handling | Validate schemas | Plus untrusted media URLs and prompt content |
A short hardening list
- Put a proxy in front and allowlist routes.
- Expose one port; firewall the rest.
- Cap tokens, context size, and concurrency per user.
- Disable dev mode, code interpreters, and dynamic adapter loading unless reviewed.
- Use separate instances for tenants that need isolation, as the vLLM guide advises.
- Test the deployed endpoint, not just the code.
Try it yourself
Run the API scan demo and look at how an unauthenticated route shows up in the results.
Click through it at your own pace, or open it full screen.
A short note on Safeguard
Safeguard offers API and web scanning and dependency scanning, which cover the endpoint and the packages behind it. Try a free scan at gold.safeguard.sh/scan.
Quick check
Is an API key on the serving runtime enough?
No. The vLLM guide says its key does not cover every route, so put a proxy in front and allowlist what is exposed.
Do we need a separate model endpoint per customer?
Where isolation matters, separate instances or a gateway with per tenant controls is the safer default. Shared instances need explicit cache and adapter controls.
Sources
Last reviewed: 19 October 2026.
