Cloudflare's zombie API endpoints need a real cleanup plan

By Greg Nowak. Last updated 2026-06-17.

Cloudflare has made stale API surface area much easier to see. API Shield can mark saved endpoints with cf-risk-zombie after 32 days without traffic, and the current docs add better ways to validate schemas, manage fallthrough behavior, and run API vulnerability scans. The hard part is still operational: deciding what is truly dead, what is just quiet, and what is still exposed because nobody owns the inventory.

For business owners, operations leads, and agency teams, the cost is rarely the label itself. It is the time spent reconciling endpoint inventories, OpenAPI files, client dependencies, and control changes without breaking live integrations. Once Cloudflare highlights a stale route, ignoring it stops being a neutral choice.

Signal	Likely meaning	Best next step
`cf-risk-zombie`	No traffic for 32 days on a saved endpoint.	Check owner, logs, schema, and client impact before removal.
In Discovery, not managed	A live route exists without formal ownership.	Save it, normalize it, and assign responsibility.
In schema, not in Discovery	The route may be low-volume, internal, or failing.	Test it directly before calling it dead.
Deletion candidate	The route looks obsolete, but its history may matter.	Capture evidence first because deleted analytics do not come back.

A practical review matrix for turning Cloudflare API Shield signals into safe cleanup decisions.

What changed

Cloudflare's November 2025 changelog says the zombie label is applied to saved endpoints that have not received traffic for 32 days and is reevaluated daily. That matters because the label is attached to a specific saved endpoint in Endpoint Management, not just a hostname. Your endpoint inventory is now part of your security backlog.

Cleanup also needs restraint. Endpoint Management starts collecting endpoint-level metrics when you save an endpoint, and Cloudflare says deleting one permanently removes its historical analytics. If a route may be useful as evidence later, capture what you need before you delete it.

Discovery is helpful, but not authoritative

API Discovery is valuable because Cloudflare normalizes similar request paths and can consolidate similar subdomains. That helps turn noisy logs into a workable map of routes.

But Discovery has limits. Current docs say traffic must return a 2xx response from the edge, must not come directly from Cloudflare Workers, and must reach at least 500 requests within 10 days. Discovery is also documented as Enterprise-only. So a missing endpoint is not automatically a retired endpoint. It may be low-volume, internal, failing, or routed in a way Discovery does not count.

A safer rule is to compare three views before retiring anything: live traffic, saved endpoints, and the schema that says what should exist.

Endpoint Management is where ownership shows up

Teams can save endpoints from Discovery, from schema uploads, or manually by method, path, and host. Cloudflare also supports variable paths and hostnames such as /api/user/{var1}/details and {hostVar1}.example.com, which is useful when one logical route has many values.

This is usually where drift becomes visible. Some routes exist in code but not in the schema. Some still serve one client or integration nobody wants to break. A useful review gives each doubtful endpoint an owner and forces one decision: document it, retire it, or keep it as a known legacy route with explicit protection.

Schema validation is where cleanup becomes control

Cloudflare's current Schema validation docs matter because validation only protects endpoints already added to Endpoint Management. If you upload a schema in the dashboard, Cloudflare can add endpoints automatically. If you manage schemas through the API or Terraform, Cloudflare says you must parse the schema and add the endpoints yourself. That is an easy place for teams to think they are protected when they are not.

The rollout model is practical. Cloudflare lets you use a global default action of Log, Block, or None, then override individual endpoints when confidence differs. It also documents a fallthrough rule for traffic that does not match Endpoint Management. That is the control that reduces zombie surface area: if a retired route still gets probed, you can catch or block it instead of leaving it in limbo.

Scanning raises the standard for your OpenAPI files

Cloudflare's current Vulnerability Scanner docs describe an API-driven beta focused on BOLA testing. To run it, you need an OpenAPI schema, a target environment, and separate owner and attacker credential sets. The API uses https://api.cloudflare.com/client/v4/, and the token needs Account > API Gateway > Edit permissions. As of June 17, 2026, the current docs say the scanner is only available for Enterprise API Shield customers.

The practical point is not just to run a scan. It is to fix the OpenAPI inputs first. Cloudflare currently accepts OpenAPI v3 schemas for Schema validation, and the scanner docs warn that large specs may need to be split into smaller files, ideally by semantic use case, to improve coverage during the beta.

A workable cleanup flow

Review zombie-labelled endpoints and confirm whether they are dead, seasonal, partner-facing, or simply quiet.
Compare Discovery, Endpoint Management, and OpenAPI before deleting anything.
Capture endpoint analytics first, because deleted history cannot be restored.
Normalize variable paths and hostnames so the inventory matches the real API shape.
Move Schema validation from Log to Block only where ownership and payload expectations are clear.
Use a fallthrough rule so unknown or retired routes do not stay silently reachable.
If you run the scanner, make the API workflow repeatable: create the scan, poll until completion, and review the report on a schedule.

This work often gets stuck between security, platform, and delivery teams. If Cloudflare is already surfacing endpoints your team does not trust, Greg can help turn that signal into a cleaner inventory, a manageable backlog, and controls that stay useful after the first sweep. Get in touch if you want help cleaning this up without breaking the routes people still depend on.

Related on GrN.dk

Need help with this kind of work?

Need help turning Cloudflare's API Shield signals into a safe cleanup and control workflow? Get in touch with Greg.

Sources

Last modified

2026-06-17