Partner API mTLS and Schema Validation With Legacy TLS Clients
CareShield Insurance exposes a partner API at api.example.com/v2/claims on Cloudflare Enterprise. Partners use client certificates issued by CareShield's PKI. The API currently accepts any client certificate signed by a public CA because the origin terminates TLS and checks only that a certificate is present. A penetration test showed a request with a valid public certificate from an unrelated domain could reach /v2/claims and, with a guessed partner ID, read a claim. CareShield wants Cloudflare to enforce mTLS before traffic reaches origin and to validate the JSON schema. Partners are on multiple clouds; 12 of 140 use old TLS 1.0 stacks and cannot upgrade for six months. The insurer has Cloudflare Enterprise with API Shield. The API handles 4,000 requests/min at peak and returns claim data classified as PHI.
1. Where should mTLS terminate, and how do you configure it without breaking the 12 legacy partners?
Read the worked answer
Terminate mTLS at the Cloudflare edge, not at the origin. Upload CareShield's partner CA to API Shield and require a client certificate on /v2/claims. Cloudflare validates the chain and can pass certificate details to the origin; the origin should no longer accept arbitrary public client certificates. This puts the authentication decision before traffic reaches the Kubernetes ingress.
The 12 legacy partners are the constraint. Do not lower the global minimum TLS version for all 140 partners. Isolate the legacy group on a separate hostname or zone with a documented exception, a minimum TLS version that matches their stack, IP allowlisting, and the same CareShield CA requirement. Give the exception an expiry date and a migration owner. The main api.example.com zone stays on a modern minimum TLS version, and the legacy path is monitored separately.
2. What does schema validation catch and not catch in this scenario?
Read the worked answer
Schema validation catches malformed JSON, wrong field types, missing required fields, unexpected fields, and requests that do not match the OpenAPI definition. It reduces parser abuse and some injection surface because the body must conform before it reaches the application. It does not catch authorization failures: a request can be perfectly schema-valid and still ask for another partner's claim by changing partnerId. The penetration test exploited exactly that gap, not a malformed body.
CareShield still needs object-level authorization in the application: bind the authenticated partner identity from the client certificate to the claim records, reject mismatched partner IDs, and log access. Add JWT or signed request validation if partners also carry user context. Schema validation is a input-shape control, not an access-control control.
3. What logging and validation would prove the fix works before general rollout?
Read the worked answer
Prove the edge rejects the pen-test case: present a certificate from an unrelated public CA to /v2/claims and confirm the TLS handshake fails at Cloudflare before the origin sees the request. Confirm a CareShield-issued certificate succeeds. Use Logpush or API Shield logs to capture mTLS handshake failures, certificate subject, schema validation results, and origin response codes. Correlate a known partner ID with the certificate identity to verify authorization.
Run a canary with a small partner group first, including one legacy partner. Compare success rates and latency. Check that the origin no longer accepts public-CA client certificates directly. Roll out to all partners only after the canary shows no unexpected 4xx spike and the authorization logs show mismatched partner IDs being denied.