arleo.euhttps://www.arleo.eu/en/Serveur personnel auto-hébergé · Infrastructure sécuriséeHugo -- gohugo.ioenFri, 08 May 2026 18:20:13 +0200Hugo SEO: Googlebot 404s, noindex aliases and sitemap normalizationhttps://www.arleo.eu/en/posts/debug-seo-404-broken-links/Fri, 29 May 2026 20:30:00 +0200Jmrhttps://www.arleo.eu/en/posts/debug-seo-404-broken-links/

Context

Google Search Console was reporting four categories of issues on arleo.eu:

  • Googlebot 404s: /fr/tag/cloudflare, /en/tag/nginx, /fr/tag/javascript… URLs with /fr/ prefix or singular /tag/ never served by nginx
  • 16 “Excluded by noindex tag” pages: all redirect pages generated by aliases: in Hugo frontmatter
  • Robots tag: noodp hardcoded in the LoveIt theme
  • FR/EN sitemap: 104 vs 105 URLs — a duplicate FR tag and two missing tags

Act 1: Hugo aliases → nginx 301 redirects

Why Hugo generates noindex pages

Hugo generates aliases: frontmatter entries as static HTML files:

]]>Hugo: freezing Mermaid diagrams to static dark/light SVGshttps://www.arleo.eu/en/posts/debug-mermaid-svg-freeze/Fri, 29 May 2026 20:00:00 +0200Jmrhttps://www.arleo.eu/en/posts/debug-mermaid-svg-freeze/

Problem

Mermaid diagrams on arleo.eu were rendering client-side via cdn.jsdelivr.net. Three concrete consequences:

  1. CSP constraint — script-src cdn.jsdelivr.net and worker-src cdn.jsdelivr.net become mandatory (Mermaid v11 uses Web Workers for its parsers).
  2. Render flash — the diagram appears after JS execution, creating a visible delay.
  3. Dark theme ignored — Mermaid initialized the SVG in light mode even when the site theme was dark.

The solution: generate SVGs at build time with mmdc, outside any browser context.

]]>CSP A+ on Hugo + Cloudflare: from hash-based to origin allowlist, auto-monitoring and hardeninghttps://www.arleo.eu/en/posts/csp-a-plus-hugo-cloudflare-origin-allowlist/Thu, 28 May 2026 23:45:41 +0200Jmrhttps://www.arleo.eu/en/posts/csp-a-plus-hugo-cloudflare-origin-allowlist/

Context

arleo.eu runs on Hugo (KVM VM) → OpenResty (NUC) → Cloudflare (CDN/WAF). Goal: A+ score on Mozilla Observatory with a strict CSP that resists edge-side injections.

The journey went through three strategies over a few weeks — nonces, hashes, then origin allowlist — before landing on a stable, automated solution.

Act 1: why hash-based failed

The initial idea seemed solid: Hugo Pipes externalizes all JS with SRI, we list the hashes in the CSP, clean result. In practice, two problems made the approach impossible.

]]>Postmortem — CrowdSec AppSec: Heuristic False Positive on Sonarr/Radarrhttps://www.arleo.eu/en/posts/postmortem-crowdsec-appsec-false-positive-sonarr/Mon, 25 May 2026 20:51:17 +0200Jmrhttps://www.arleo.eu/en/posts/postmortem-crowdsec-appsec-false-positive-sonarr/

Summary

On May 25, 2026 at around 10:02 PM (local time), Sonarr and Radarr became completely inaccessible from the home IP (82.XX.XX.XX), returning 403 on every URL including /login. The service was fully operational. Initial suspicion fell on the day’s crowdsec-cf-sync refactor deployment — the real cause was a CrowdSec AppSec heuristic false positive.

Timeline

Time (local) Event
~10:00 PM Sonarr browser session cookie expired
10:02:31 PM Browser loads Sonarr library → attempts to fetch 20+ /MediaCover/*.jpg simultaneously
10:02:31 PM Sonarr returns 302 → /login for each image (invalid session)
10:02:34 PM SignalR WebSocket connection succeeds (101) via access_token in URL
~10:05 PM CrowdSec AppSec triggers heuristic rule http-probing: burst of failed requests from same IP
10:11:37 PM All requests from 82.XX.XX.XX return 403 — cs_reason=heuristic in nginx logs
10:13:34 PM Even /login is blocked — IP cannot authenticate

Root Cause

CrowdSec AppSec maintains an in-memory heuristic state, separate from LAPI decisions. When the browser simultaneously tries to load many resources and receives 302/403 from the upstream application (Sonarr), AppSec interprets the burst of failures as aggressive probing (http-probing) and blocks the source IP.

]]>CrowdSec AppSec + OpenResty: Modern WAF Without ModSecurityhttps://www.arleo.eu/en/posts/crowdsec-appsec-openresty/Mon, 18 May 2026 00:07:55 +0200Jmrhttps://www.arleo.eu/en/posts/crowdsec-appsec-openresty/

After years running ModSecurity + OWASP CRS on nginx, I migrated arleo.eu to a more modern stack: CrowdSec AppSec on OpenResty. The result is a tighter inline WAF architecture — better integrated, easier to maintain, and fully coherent with the rest of the security stack.

Why Drop ModSecurity?

ModSecurity v2 is in maintenance mode. Managing OWASP CRS rules on classic nginx generates friction: frequent false positives, logs that are hard to correlate with CrowdSec, and a configuration spread across multiple tools with no unified view.

]]>SRI on Hugo: automated hashes, auto-update and BetterStack alertinghttps://www.arleo.eu/en/posts/sri-cdn-hugo-automate/Sun, 17 May 2026 00:00:00 +0000Jmrhttps://www.arleo.eu/en/posts/sri-cdn-hugo-automate/

Why SRI?

When your site loads resources from a third-party CDN — FontAwesome, Mermaid, Animate.css — you’re trusting an external party you have no control over. If jsdelivr.net gets compromised, or if a supposedly immutable version is silently mutated, your site can become an attack vector.

Subresource Integrity (SRI) solves this cleanly: every <link> or <script> tag carries an integrity="sha256-…" attribute that the browser verifies before executing the resource. If the hash doesn’t match, the browser blocks the load.

]]>CSP Hash on Hugo: migrating from nonce to hash to preserve CDN cachehttps://www.arleo.eu/en/posts/csp-hash-hugo/Sat, 16 May 2026 00:00:00 +0000Jmrhttps://www.arleo.eu/en/posts/csp-hash-hugo/<div class="featured-image"> <img src="/images/csp-hash-hugo-featured.png" referrerpolicy="no-referrer"> </div>CSP nonces and CDN caching are incompatible by design. On a Hugo static site, SHA-256 hashes are the native approach: computed at build time, stable across requests, and fully compatible with Cloudflare caching.Postmortem: TypeIt broken by Mermaid in LoveIt themehttps://www.arleo.eu/en/posts/postmortem-typeit-mermaid/Thu, 14 May 2026 09:46:31 +0200Jmrhttps://www.arleo.eu/en/posts/postmortem-typeit-mermaid/

TL;DR

The LoveIt theme’s typewriter animation (TypeIt) stopped working on the home after adding Mermaid diagrams to posts. Cause: a #id-1 DOM selector shared between both libraries. When Mermaid finds an orphan block in a home summary, its initialization crashes, and the JS init chain stops before reaching TypeIt. Fix: add `

]]>hugo-mcp Cloudflare plugin: smart cache purgehttps://www.arleo.eu/en/posts/hugo-mcp-plugin-cloudflare/Thu, 14 May 2026 09:43:19 +0200Jmrhttps://www.arleo.eu/en/posts/hugo-mcp-plugin-cloudflare/

TL;DR

The Cloudflare plugin in hugo-mcp v2.0 implements 3 cache purge modes (full, partial, smart). The partial mode computes the linked URLs to invalidate (canonical + sitemap + RSS + listing + home) to preserve 95% of the CDN cache on every modification. Concretely: 6 URLs purged instead of wiping everything. This post details the computation, the pitfalls, and why smart became the default.

]]>NUC Security Audit: ModSecurity Removed, 500 MB Recoveredhttps://www.arleo.eu/en/posts/audit-securite-modsecurity-crowdsec/Thu, 14 May 2026 05:32:19 +0200Jmrhttps://www.arleo.eu/en/posts/audit-securite-modsecurity-crowdsec/

⚡ TL;DR

A security stack audit on the homelab NUC reveals redundant double WAF inspection: ModSecurity + OWASP CRS load 11,872 rules into memory despite SecRuleEngine Off, running in parallel with CrowdSec AppSec which already covers the same surface. After removing the ModSecurity nginx module and five other targeted fixes, nginx drops from ~520 MB to ~27 MB PSS. Same security, memory footprint divided by 20.

🏗️ Architecture Before the Audit

The security stack had six stacked layers:

]]>