I recently encountered a frustrating issue where syntax highlighting worked
perfectly when running zola serve
locally, but completely disappeared
when deployed to Cloudflare Pages. Here's how I diagnosed and fixed the
problem.
The Symptoms
The issue manifested in two ways:
-
Visual difference: Locally, my code blocks had proper syntax highlighting with colors, but on the deployed site, they appeared as plain text with no styling.
-
HTML inspection revealed the problem: When I examined the generated HTML locally, I could see inline styles with color properties:
<span style="color:#bf616a;">#!/bin/bash</span>
But on the Cloudflare Pages deployment, the same elements had empty style attributes:
<span style="">#!/bin/bash</span>
Initial Investigation
My first assumption was that this was a Zola build configuration issue. I
was using Cloudflare Pages with a custom build setup via
UNSTABLE_PRE_BUILD
:
asdf plugin add zola https://github.com/salasrod/asdf-zola && asdf install zola 0.20.0 && asdf global zola 0.20.0
I initially suspected:
- Missing CSS generation during build
- Incorrect
config.toml
settings for syntax highlighting - Build environment differences between local and Cloudflare
The Real Culprit: Content Security Policy
The breakthrough came when I checked the browser console and found multiple CSP (Content Security Policy) errors:
Content-Security-Policy: The page's settings blocked an inline style (style-src-attr) from being applied because it violates the following directive: "style-src 'self'"
Additional related errors included:
Loading failed for the <script> with source "https://static.cloudflareinsights.com/beacon.min.js/vcd15cbe7772f49c399c6a5babf22c1241717689176015".
Content-Security-Policy: The page's settings blocked a script (script-src-elem) at https://static.cloudflareinsights.com/beacon.min.js/... from being executed because it violates the following directive: "script-src 'self'"
Content-Security-Policy: The page's settings blocked a style (style-src-elem) at https://fonts.googleapis.com/css2?family=IBM+Plex+Mono:ital,wght@0,400;0,700;1,400;1,700&display=swap from being applied because it violates the following directive: "style-src 'self'"
The Root Cause
The issue wasn't with Zola's build process at all. Cloudflare Pages was correctly generating the HTML with inline styles, but my overly restrictive Content Security Policy was stripping them out at runtime.
My original _headers
file was:
/*
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; style-src 'self'; img-src 'self'; frame-ancestors 'none';
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
The style-src 'self'
directive was blocking all inline styles, including
Zola's syntax highlighting.
The Solution
I updated my static/_headers
file to allow the necessary resources while
maintaining security:
/*
X-Frame-Options: DENY
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; script-src 'self' https://static.cloudflareinsights.com; object-src 'none'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self'; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://cloudflareinsights.com; frame-ancestors 'none';
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Key Changes Made
'unsafe-inline'
instyle-src
: Allows Zola's inline syntax highlighting styleshttps://fonts.googleapis.com
instyle-src
: Permits Google Fonts CSShttps://fonts.gstatic.com
infont-src
: Allows Google Fonts files to loadhttps://static.cloudflareinsights.com
inscript-src
: Enables Cloudflare Analyticshttps://cloudflareinsights.com
inconnect-src
: Allows analytics connections
Lessons Learned
-
Browser console is your friend: The CSP errors in the console immediately pointed to the real issue, saving hours of debugging Zola configuration.
-
Security vs. functionality trade-offs: While
'unsafe-inline'
reduces security slightly, it's necessary for many static site generators that rely on inline styles. -
Test in production: Issues like this only surface in the deployed environment, not during local development.
-
CSP debugging: Tools like
curl -I
can help verify which headers are being served:curl -I https://peterbabic.dev | grep -i content-security-policy
After deploying the updated headers, syntax highlighting worked perfectly, and all console errors disappeared. The fix was simple once the real problem was identified – sometimes the issue isn't where you first expect it to be. Enjoy!