// Discovery · Schema Validation · Sensitive Data Detection — one fake e-commerce API
// API Shield runs at Cloudflare's edge before this Worker ever sees the request
One API. Three layers of protection. Zero origin code changes.
Cloudflare watches every request and learns your API surface automatically. Endpoints you forgot, internal tools that leaked to production, old versions still answering — all surfaced in Endpoint Management within minutes.
// fake e-commerce API on apishield.nobledemos.com — 4 documented · 4 shadow
GET /api/v1/productsGET /api/v1/products/sku_001POST /api/v1/ordersGET /api/v1/users/meGET /api/v1/internal/debugGET /api/v1/admin/users/dumpGET /api/v0/legacy/checkoutGET /api/v1/_health/full// Every endpoint above returns 200 OK from the Worker — Discovery's job is to tell you they exist, not block them. Pillars 02 and 03 add the enforcement.
Run a few curls above (or just refresh this page a couple of times — every link counts as traffic). Then open Security › API Shield › Endpoint Management in the Cloudflare dashboard for nobledemos.com.
Within ~5 minutes, every endpoint you hit appears in the list. Endpoints not in your uploaded OpenAPI schema are tagged as shadow and surfaced for review. You can then save them to the schema, label them internal, or block them outright with a Custom Rule.
Note: Discovery uses ML to template paths like /products/sku_001 → /products/{id} automatically.
The OpenAPI spec you already maintain becomes an edge-enforced firewall. Cloudflare blocks any request whose body, headers, or query don't match — missing fields, wrong types, extra fields (mass-assignment), out-of-range values — before they reach your origin. Zero code changes.
// rule active: POST /api/v1/orders · validated against CreateOrderRequest · action block
{"productId":"sku_001","qty":2}{"qty":2}{"productId":"sku_001","qty":"two"}{"productId":"sku_001","qty":2,"isAdmin":true}{"productId":"sku_001","qty":9999}{"productId":"<script>","qty":2}// Blocks return Cloudflare's API Shield error response (HTTP 403). The Worker never sees these requests — schema mismatches are enforced at the edge.
1. Upload the schema: Security › API Shield › Schema Validation › Add validation. Use the file apps/api-shield/openapi.yaml from this repo.
2. When prompted, set the default action to Block (or Log first if you want to dry-run). Apply to operation POST /api/v1/orders.
3. Save. Run the curls above — invalid bodies return 403, valid ones return 201 from the Worker.
// Validation includes path params, query strings, headers, and request body. additionalProperties: false on the schema is what makes mass-assignment attacks fail.
Even with discovery and validation in place, the worst leaks happen on the way out — a misconfigured endpoint that returns full credit cards, an internal tool that leaks an AWS key. Cloudflare scans response bodies at the edge and flags (or blocks) them before they reach the client.
// SDD active on apishield.nobledemos.com · detectors: Financial · PII (US) · Secrets
GET /api/v1/users/me/walletGET /api/v1/integrations/keysGET /api/v1/users/me// All values returned are publicly-known test fixtures (Stripe test cards, IRS demo SSN, AWS docs example keys) — no real PII / secrets.
1. Open Security › Sensitive Data on nobledemos.com. Cloudflare ships a Managed Ruleset called Cloudflare Sensitive Data Detection with detectors for credit cards, US/EU PII, and common secret patterns.
2. Enable the ruleset and set the action — Log first to see what fires, then flip to Block once you've reviewed the matches.
3. Optional: in Security › API Shield › Endpoint Management, the two leaky endpoints will be tagged "contains sensitive data" after a few requests — making it obvious which APIs need attention.
// SDD inspects response bodies; the Worker still emits the raw payload, but Cloudflare rewrites it (or blocks the response) at the edge based on your action setting.