Configure CDN Caching

Overview

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.

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.

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

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

Prerequisites

• Completed domain deployment

• WAF SaaS profile attached to the asset

Enable CDN Caching

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

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

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.

Path Matching

Path matching is based on pattern matching.

• Matching is case-sensitive

• A leading / is optional and implicitly assumed

Supported Wildcards

• * — matches 0 or more characters

• ? — matches exactly 1 character

Examples

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

Additional Constraints

• Maximum pattern length is 255 characters

• Patterns are case-sensitive (e.g., *.jpg does not match LOGO.JPG)

• Supported Characters: _ - . * $ / ~ " ' @ : + &

Most Specific Match Wins

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

Parameters:

• /a/*

• /a/b/*

Request: /a/b/file.png

→ /a/b/* is applied

Example

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.

Caching Policy

Caching policies define how responses are cached.

TTL (Time to Live)

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

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

• 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

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

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.

Sharing Parameters Across Practices

• 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

• Executed asynchronously

• Applied per domain

• May take several minutes

Cache invalidation forces cached content to be refreshed.

Cache invalidation is currently available via UI only

CDN API

CDN caching configuration is available via the GraphQL API.

You can:

• Create and update caching practices

• Create and update caching parameters

Cache invalidation is not currently available via the API

API Access

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

Queries

• Query.getCachingConfigurationParameter

• Query.getAllCachePolicies

• Query.getCachingPractice

Mutations

• Mutation.newCachingConfigurationParameter

• Mutation.updateCachingConfigurationParameter

• Mutation.newCachingPractice

• Mutation.updateCachingPractice