Advanced tutorial: Creating CDN/WAF rules as code

This tutorial is for teams who already use a CDN / WAF with programmable rules (JSON, API, or “infrastructure as code”). SwiftPress runs behind edge caching and security; understanding cache bypass for WordPress cookies helps you reason about admin sessions, cart/checkout, and personalised responses.

Note: Exact field names, operators, and export formats depend on your edge provider’s product. The example below is illustrative—use your vendor’s documentation for production rules.

---

Why “rules as code”?

Defining CDN/WAF behaviour as structured data (JSON, Terraform, API payloads) instead of only clicking in a UI gives you:

Security rules (WAF) and delivery rules (cache, redirects) both benefit from this discipline.

---

Example: WordPress cache bypass on cookies

Anonymous visitors can usually be served cached HTML from the edge for speed. Logged-in editors, WooCommerce shoppers, or anyone with session cookies often need fresh HTML from origin—otherwise they might see another user’s cached page or stale admin bars.

A common pattern is: if the request carries WordPress-related cookies, do not serve a shared HTML cache for that request—bypass (or “miss through”) to the origin.

Example rule (illustrative JSON)

{
  "id": "rule_1767379981529",
  "name": "WordPress Cache Bypass",
  "description": "Bypass edge HTML cache when WordPress/session cookies are present.",
  "enabled": true,
  "priority": 1,
  "expression": {
    "or": [
      {
        "field": "http.cookie",
        "op": "matches",
        "value": "(wordpress_test_cookie|PHPSESSID|wp-settings|wordpress|wp)"
      }
    ]
  },
  "action": {
    "type": "cache_bypass"
  }
}

Field by field

• name / description — Human-readable; helps operators know why the rule exists.

• enabled — Toggle without deleting the rule.

• priority — Lower numbers often run first (check your platform). Order matters when multiple rules overlap.

• expression — When this evaluates true, the action runs.

• expression.or — At least one inner condition must match (here there is only one branch).

• field: "http.cookie" — Inspect the Cookie header on the request.

• op: "matches" — Treat value as a regular expression (implementation-dependent—confirm regex flavour in your provider’s docs).

• value — Matches common WordPress / PHP session patterns, for example:

  • wordpress_test_cookie — WordPress login flow / tests.
  • PHPSESSID — Generic PHP session (some plugins/themes).
  • wp-settings-* — User preferences (often long-lived).
  • wordpress_* / wp — Broader patterns—tune these for your site so you don’t bypass cache unnecessarily (too broad = less cache hit rate).

• action.type: "cache_bypass" — For matching requests, do not satisfy the request from a shared full-page cache of anonymous HTML; fetch from origin (or use a more granular cache policy, depending on product).

---

Why this pattern is “good”

1. Correctness — Logged-in and session traffic gets origin-rendered responses, reducing risk of cached private or personalised content being shown to the wrong visitor.
2. Performance where it counts — Anonymous traffic still hits fast cache; only “special” requests pay the PHP/origin cost.
3. Explicit policy — The rule states which signals (cookies) trigger bypass, so you can audit and narrow over time.

Caveat: Overly broad regexes (e.g. matching wp everywhere) can reduce cache hit ratio. Prefer specific cookie names your stack actually sets, and measure hit rates after changes.

---

WAF vs CDN in one sentence

• CDN rules here control caching and delivery (e.g. bypass, TTL, vary headers).
• WAF rules control allow/block/challenge based on IP, URI, body, bots, etc.

The same “as code” workflow applies to both; keep separate rule sets for clarity.

---

Next steps

• Align cookie names with your plugins (WooCommerce, LMS, membership).
• Test with and without cookies using curl or browser Network tools.
• Coordinate with Caching plugins on SwiftPress so WordPress-side cache layers don’t fight edge behaviour.