> For the complete documentation index, see [llms.txt](https://waf-doc.inext.checkpoint.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://waf-doc.inext.checkpoint.com/getting-started/deploy-enforcement-point/waf-as-a-service-waf-saas/configure-cdn-caching.md).

# Configure CDN Caching

### Overview <a href="#cdncachingdocumentation-overview" id="cdncachingdocumentation-overview"></a>

CDN caching enables you to control how your web application assets are cached at the edge.

By defining caching parameters and applying them to specific URL paths, you can:

* Reduce origin load
* Improve response latency
* Control cache freshness

CDN caching is configured per asset using a **CDN Caching practice** and **Caching Configuration parameters**, available via the **CDN Caching tab** in the asset view.

{% hint style="info" %}
Available only for assets associated with a WAF SaaS profile.\
If no WAF SaaS profile is attached, the CDN Caching tab displays a placeholder indicating that the feature is available only for assets with WAF SaaS profile.
{% endhint %}

{% hint style="info" %}
**Planned Enhancements:**

* Path-based invalidation
* Improved invalidation status visibility
* Cache monitoring (hit/miss ratio insights)

If you're interested in any of the enhancements reach out to your check point contact
{% endhint %}

#### **Limitations:**

* Assets sharing the same domain must use identical caching configuration if CDN caching is enabled on more than one of them
* Two parameters within the same practice cannot define identical path patterns
* Root domains are currently not supported
* Only HTTPS (port 443) is supported
  * Non-standard ports are not supported

### Configuration <a href="#cdncachingdocumentation-prerequisites" id="cdncachingdocumentation-prerequisites"></a>

#### Prerequisites <a href="#cdncachingdocumentation-prerequisites" id="cdncachingdocumentation-prerequisites"></a>

* Completed domain deployment
* WAF SaaS profile attached to the asset

#### Enable CDN Caching <a href="#cdncachingdocumentation-enablingcdncaching" id="cdncachingdocumentation-enablingcdncaching"></a>

CDN caching can be configured either during asset creation or on an existing asset.

* During asset creation: CDN caching can be enabled as part of the setup wizard.\
  When enabled, the created asset is automatically associated with a default CDN Caching practice, including predefined caching parameters.
  * **Default Caching Parameters:**
    * System-defined and **read-only**
    * Cannot be edited
    * Can be removed from a practice
    * Additional parameters can be created and added
* For an existing asset with a WAF SaaS profile, navigate to the CDN Caching tab to create a new practice and define or attach caching parameters.

CDN caching is managed using **practices** and **parameters**:

* **Practice:** controls whether CDN caching is enabled
* **Parameter:** defines how requests matching specific paths are cached

### Practice  <a href="#cdncachingdocumentation-practiceview" id="cdncachingdocumentation-practiceview"></a>

<figure><img src="/files/9oZrozDXzBY56qxm0q4v" alt=""><figcaption></figcaption></figure>

Each Practice includes:

* **Parameters** – Name of the caching parameters
* **Paths** – URL patterns matched by the parameter
* **Caching Policy** – Defines TTL and cache key behavior
* **Used By** – Number of assets using this parameter

The toolbar allows creating, editing, and removing parameters.

### Parameter  <a href="#cdncachingdocumentation-parameterconfiguration" id="cdncachingdocumentation-parameterconfiguration"></a>

<figure><img src="/files/eblzYcDg0dDzBlr5bK1e" alt="" width="270"><figcaption></figcaption></figure>

<figure><img src="/files/iEHtyAtfCVtYwB8RfW76" alt="" width="272"><figcaption></figcaption></figure>

Each parameter includes:

* **Name**
* **Paths** – URL path patterns
* **Caching Policy** - Cache behavior settings, including:
  * TTL
  * Headers
  * Query strings
  * Cookies

Each Parameter also offers a "Used By" view, which indicates by what assets and domain it is used and also allows direct navigation to each asset.<br>

<figure><img src="/files/yCONqfwRgiA1UIzpX60t" alt="" width="269"><figcaption></figcaption></figure>

<details>

<summary>Path Matching</summary>

Path matching is based on pattern matching.

* Matching is case-sensitive
* A leading `/` is optional and implicitly assumed

### Supported Wildcards <a href="#cdncachingdocumentation-supportedwildcards" id="cdncachingdocumentation-supportedwildcards"></a>

* `*` — matches 0 or more characters
* `?` — matches exactly 1 character

### Examples <a href="#cdncachingdocumentation-examples" id="cdncachingdocumentation-examples"></a>

|              |                    |
| ------------ | ------------------ |
| `/images/*`  | `/images/logo.png` |
| `*.jpg`      | `image.jpg`        |
| `/file?.txt` | `/file1.txt`       |
| `/api/v1/*`  | `/api/v1/users`    |

#### Additional Constraints <a href="#cdncachingdocumentation-additionalconstraints" id="cdncachingdocumentation-additionalconstraints"></a>

* Maximum pattern length is 255 characters
* Patterns are case-sensitive (e.g., `*.jpg` does not match `LOGO.JPG`)
* Supported Characters: `_ - . * $ / ~ " ' @ : + &`

#### Most Specific Match Wins <a href="#cdncachingdocumentation-mostspecificmatchwins" id="cdncachingdocumentation-mostspecificmatchwins"></a>

When multiple parameters match a request, the most specific path pattern is applied.

More specific patterns:

* Match a narrower set of requests
* Contain fewer wildcards
* Include longer or more detailed paths

#### Example <a href="#cdncachingdocumentation-example" id="cdncachingdocumentation-example"></a>

Parameters:

* `/a/*`
* `/a/b/*`

Request:\
/a/b/file.png

→ `/a/b/*` is applied

#### Example <a href="#cdncachingdocumentation-example.1" id="cdncachingdocumentation-example.1"></a>

Parameters:

* `*.jpg`
* `/images/*.jpg`

Request:\
/images/logo.jpg

→ `/images/*.jpg` is applied

> Evaluation is based on specificity, even if parameters are displayed alphabetically in the UI.

</details>

<details>

<summary>Caching Policy</summary>

Caching policies define how responses are cached.

#### TTL (Time to Live) <a href="#cdncachingdocumentation-ttl-timetolive" id="cdncachingdocumentation-ttl-timetolive"></a>

TTL determines how long a response is cached.

* Default TTL is used when no caching headers are present
* Minimum TTL enforces a lower bound
* Maximum TTL enforces an upper bound

TTL works together with response headers to determine the final cache duration.

#### Cache Key <a href="#cdncachingdocumentation-cachekey" id="cdncachingdocumentation-cachekey"></a>

The cache key determines whether requests are treated as identical or different.

It is based on selected request attributes such as:

* Headers
* Query strings
* Cookies

#### Key Behavior <a href="#cdncachingdocumentation-keybehavior" id="cdncachingdocumentation-keybehavior"></a>

* If a value is **included** in the cache key → requests with different values are cached separately
* If a value is **ignored** → requests are treated as identical for caching purposes

#### Example <a href="#cdncachingdocumentation-example.2" id="cdncachingdocumentation-example.2"></a>

If query strings are ignored:

* `/image.png?size=small`
* `/image.png?size=large`

→ Both requests may use the same cached response

If query strings are included:\
→ Each variation may create a separate cache entry

Choosing fewer attributes increases cache hit ratio, while including more attributes increases granularity.

#### Cache Hit vs Miss <a href="#cdncachingdocumentation-cachehitvsmiss" id="cdncachingdocumentation-cachehitvsmiss"></a>

Cache behavior can be inspected using tools such as `curl` by checking response headers.

For example:

curl -I <https://example.com/file.jpg>

Depending on the environment and configuration, response headers may indicate whether the response was served from cache or fetched from the origin.

</details>

#### Sharing Parameters Across Practices <a href="#cdncachingdocumentation-sharingparametersacrosspractices" id="cdncachingdocumentation-sharingparametersacrosspractices"></a>

* Default parameters cannot be edited
* The **Used By** view provides visibility into all usages

**Additional Notes:**

* A parameter can be used in multiple practices
* Changes affect all usages
* Removing a parameter from a practice does not delete it

Caching parameters are reusable across multiple practices and assets.

### Cache Invalidation

<figure><img src="/files/HMcCXppwFvP9jLaXv6at" alt=""><figcaption></figcaption></figure>

* Executed asynchronously
* Applied per domain
* May take several minutes

Cache invalidation forces cached content to be refreshed.

{% hint style="info" %}
Cache invalidation is currently available via UI only
{% endhint %}

<details>

<summary>CDN API</summary>

CDN caching configuration is available via the GraphQL API.

You can:

* Create and update caching practices
* Create and update caching parameters

{% hint style="info" %}
Cache invalidation is not currently available via the API
{% endhint %}

#### API Access <a href="#cdncachingdocumentation-apiaccess" id="cdncachingdocumentation-apiaccess"></a>

The API can be accessed using GraphQL clients (such as Postman), or via the Infinity Portal:

<https://portal.checkpoint.com/dashboard/appsec/cloudguardwaf#/waf-support/api/>

#### Available Operations <a href="#cdncachingdocumentation-availableoperations" id="cdncachingdocumentation-availableoperations"></a>

#### Queries <a href="#cdncachingdocumentation-queries" id="cdncachingdocumentation-queries"></a>

* Query.getCachingConfigurationParameter
* Query.getAllCachePolicies
* Query.getCachingPractice

#### Mutations <a href="#cdncachingdocumentation-mutations" id="cdncachingdocumentation-mutations"></a>

* Mutation.newCachingConfigurationParameter
* Mutation.updateCachingConfigurationParameter
* Mutation.newCachingPractice
* Mutation.updateCachingPractice<br>

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://waf-doc.inext.checkpoint.com/getting-started/deploy-enforcement-point/waf-as-a-service-waf-saas/configure-cdn-caching.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.