Cloudflare, CDN, WAF and R2 Concepts

1. The problem: “it is behind Cloudflare” is not a complete technical conclusion

A hostname behind an edge platform can involve several independent systems: DNS proxying, edge ingress, WAF evaluation, cache behavior, origin routing, and sometimes R2. A green dashboard state or a 200 response cannot prove every layer.

The owned artifact is Edge Delivery Policy Evidence Record v1. It records direct observation, inference, unknowns, and bounded recovery/defer decisions independently for each layer.

2. Proxied DNS establishes an ingress path, not application correctness

Cloudflare Rules requires proxied DNS records for rule features that need traffic to pass through the Cloudflare network. That is a routing/platform condition, not proof that application behavior, origin authorization, or cache policy is correct.

In the evidence record, first establish whether the request entered the edge path. Then evaluate WAF and cache decisions separately.

3. WAF is a rule engine with expressions and actions

Cloudflare WAF evaluates web and API requests with rules and rulesets. A rule defines a filter and an action, and terminating actions can stop later evaluation.

If a header or path causes a rule to match, record that conclusion at the WAF layer. A blocked request does not by itself prove an origin failure or the absence of application vulnerabilities.

4. Treat false positives and bypass risk as separate concerns

A WAF can block a legitimate request or use a rule that is too broad or too narrow. “WAF enabled” is therefore not equivalent to “security solved.”

One local fixture changes a request header so the decision moves from allow to block while origin state remains constant. Correct diagnosis keeps the cause at the WAF layer.

5. CDN cache is independent from application correctness

Cache decides whether a response can be served from the edge or must be fetched from a lower layer. HIT, MISS, STALE, and BYPASS are cache observations; none alone proves content correctness, freshness suitability, or authorization.

Record cache state together with cache-key dimensions and freshness evidence, and keep application conclusions separate.

6. Cache key and freshness are causal inputs

Requests that look similar can map to different cache keys because of headers, cookies, query values, or configured rules. A HIT can also be too old for the intended policy.

The lab changes only cache-key/freshness metadata in one case. The supported conclusion is that cache behavior changed, not that an application defect was proven.

7. Keep origin-path evidence separate from edge observations

The edge can block a request, satisfy it from cache, or route it to origin. Edge observation and origin observation are not the same evidence.

If origin health remains constant while WAF blocks the request, keep the diagnosis at WAF. If cache moves to MISS, inspect route/fetch evidence before claiming an origin fault.

8. R2 buckets are private by default

Current Cloudflare documentation states that R2 buckets are private by default. Attaching a Custom Domain creates a public delivery path that can use Cloudflare Cache.

Do not treat public delivery as private-object authorization. Presigned/private object access belongs to OPS-007.

9. Custom Domain, Cache and WAF form distinguishable stages

Cloudflare documents a public R2 flow in which WAF runs before Cache and R2. Invalid requests can therefore be rejected before consuming cache or object-store work.

That ordering is useful evidence for the documented path, but it is not a universal ordering claim for every Cloudflare product and topology.

10. “S3-compatible” means bounded compatibility that must be checked

R2 exposes an S3-compatible API, but its compatibility matrix includes implemented, experimental, and unimplemented behavior and can change over time.

Check the required capability against current R2 documentation. Familiarity with Amazon S3 is not sufficient evidence that R2 supports the same feature.

11. Separate direct observation, inference and unknowns

For example, WAF rule X matched can be a direct observation while origin is broken may only be an inference. If the request never reached origin, that inference is not closed by evidence.

The evidence record keeps observation, inference, and unknowns separate for each layer. Unsupported conclusions remain OPEN.

12. Recovery must be layer-specific

A WAF false positive may require changing the expression and replaying the local request. A cache anomaly may require correcting key/freshness policy and comparing response evidence. An unsupported R2 capability may require a bounded alternative or defer decision.

A generic restart or unexplained bypass is not recovery proof; recovery evidence must address the responsible layer.

13. Edge Delivery Policy Evidence Record v1

The record includes request facts, proxied-edge assumption, WAF match/action, cache state/key/freshness, origin route, R2 path, compatibility requirement/result, direct observation, inference, unknowns, failure layer, recovery check, and final decision.

This artifact is a MAKNOW instructional synthesis, not a Cloudflare-mandated operational form.

14. Lab and transfer

The lab is completely offline: eight synthetic fixtures provide request headers, WAF rules, cache ledger rows, origin state, R2 route state, and a local compatibility snapshot. No real zone, credential, DNS change, or network request is used.

The transfer case changes header, cache key, route, and capability requirement. No baseline verdict can be copied; every layer is recomputed from the changed evidence.

15. Sources, freshness, and claim limits

On 2026-09-19, official Cloudflare documentation was rechecked: Rules still requires proxied DNS for traffic to pass through the Cloudflare network; WAF still defines filtering through rules/rulesets; R2 remains S3-compatible with explicit differences; and R2 buckets remain private by default with Custom Domain used for cache/public delivery.

The next volatile-source review is due 2026-10-17. No dashboard state, cache HIT, WAF presence, or S3 familiarity is treated as general proof of security or correctness.