Setup CDN and WAF

April 25, 2024


We are thrilled to assist you in configuring your Content Delivery Network (CDN) and/or Web Application Firewall (WAF), depending on your contract. Before beginning the CDN/WAF setup, there is a prerequisite that involves using a dedicated URL for the Jahia contribution interface.


Accessing the edition/contribution interface is not supported trough the CDN/WAF.

To ensure a smooth setup, please complete the following prerequisite:

  1. Dedicated Domains: Use dedicated domains for the Jahia contribution interface. Suggested domains include:
    • Contribution Interface: (Note that it can also be your technical domain) 
    • Public Interface:

Let us know once you have completed this step so that we can proceed to the next phase.


Note regarding CDN/WAF compatibility with Blue/Green upgrades:

We have two options for ensuring compatibility:

Option 1:

The customer creates a new DNS protected by their certificate, for example, and adds this DNS to their production environment on Jahia Cloud. We will then use this DNS as the origin for CloudFront distribution.

Option 2:
The customer already has a wildcard certificate on Jahia Cloud, in which case we can use a fake DNS that doesn't exist but points to the correct region resolvers, for example In this case, no further action is required from the customer.

Information Request

Before initiating the setup, we kindly request the following information for each domain you wish to configure:

  1. Domain Name: [e.g.,]
  2. SSL Certificate: Provide the SSL certificate for the domain in PEM format, including wildcard or multi-domain certificates if applicable. Additionally, include the certificate chain.

Once we receive this information, our team will start the setup process and ensure the seamless operation of your CDN and WAF.

CDN/WAF Setup Process

The Jahia Cloud Team will handle the setup process, including the creation of the CDN/WAF distribution. This will result in the generation of a dedicated CloudFront URL that redirects to your Jahia Cloud environment. The team will upload the SSL certificate and provide you with the CloudFront URL. The URL provided will look like

Testing & Validation 

You simply need to add entries in your host file pointing to (the production CDN endpoint) for Then, you be able to see hits and misses from CloudFront in the headers when you access the site. Make sure to test all site features.

DNS Configuration

To complete the setup, you need to create a CNAME in your DNS configuration to redirect to the CloudFront URL However, note that the contribution domain ( should point directly to the Jahia environment.

Caching Rules 

We are caching the following types of assets for a one hour duration. 

  • AVI files (*.avi)
  • BMP images (*.bmp)
  • CSS files (*.css)
  • GIF images (*.gif)
  • ICO files (*.ico)
  • JPG images (*.jpg)
  • JPEG images (*.jpeg)
  • JavaScript files (*.js)
  • MKV files (*.mkv)
  • MP3 audio files (*.mp3)
  • MP4 video files (*.mp4)
  • OGG audio files (*.ogg)
  • PDF documents (*.pdf)
  • PNG images (*.png)
  • SVG images (*.svg)
  • Compressed SVG files (SVGZ) (*.svgz)
  • WEBM video files (*.webm)
  • WEBP images (*.webp)
  • WOFF font files (*.woff)
  • WOFF2 font files (*.woff2)
  • XML files (*.xml)

Cache Invalidation

As a general rule, an asset is invalidated in CloudFront when its URL is updated. This means that CloudFront can invalidate an asset when the URL of the asset changes. 

To ensure that your application's assets are updated correctly when changes are made. You can achieve this by using the "addLastModifiedDateInAssets" property. The 'addLastModifiedDateInAssets' feature is implemented at the static asset filter level, appending the lastModified parameter to the URL of included static assets when enabled. This property allows you to force the CDN to reload assets when they are updated. More info here

As part of the new webpack approach in (Jahia 8.2) demonstrated here, [hash] can be added in webconfig output filename as a way to generate a new name whenever bundled content has been changed.

From npm-modules, files are generated with chunk hash filenames, but does not necessarily change whenever content changes. However all static assets also goes through the standard static asset filters and generates a unique compiled js, css etc, so it generates a unique file everytime a new module version is deployed.

WAF Rules

The WAF is administered by Jahia and is providing the needed security for all of our customers. The WAF relies on a set of rules defined by our Cloud and Security team. Here are the list of rules we are using for our WAF, and this applies to all of our customers. 

Rule 1: BotControl

  • Blocks bot traffic and automated attacks, including known bots and scripts that attempt to compromise web applications. 

Rule 2: Known Bad Inputs

  • Blocks known malicious inputs, such as SQL injection attacks, cross-site scripting (XSS) attacks, and other forms of input-based attacks.

Rule 3: Linux

  • Blocks Linux-based attacks and vulnerabilities, including known exploits and suspicious behavior.

Rule 4: Unix

  • Blocks Unix-based attacks and vulnerabilities, including known exploits and suspicious behavior.

Rule 6: SQL Injection

  • Blocks SQL injection attacks, which can be used to extract sensitive data or take control of a database.

Rule 7: Common

  • Provides basic security and protection for the web application, including rules for common web attacks and vulnerabilities.

Rule 8: Rate Limit

  • A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule aggregates requests based on the rule's 5-minute window, if the count of the requests for the same source IP exceeds a certain threshold, the IP will be temporarily blocked for a one-hour duration.