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.

⚡ 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:

TL;DR

On May 9, 2026, I delivered all 10 chantiers of the MCP security sprint that I had announced earlier in the day in a single marathon session. hugo-mcp is now at v1.9.0 (GitHub Release), commit 1404f83 GPG-signed.

Here’s the high-level recap + a pedagogical deep-dive on 2 chantiers with real value beyond my specific context: C2 token rotation and C6 internal TLS.

Recap of 10 chantiers

Full details in the CHANGELOG v1.9.0 and commit 1404f83.

Status: ✅ DELIVERED — sprint closed on May 9, 2026

Update May 9, 2026 (end of session): all 10 chantiers delivered in a single marathon session, and all 3 coordinated releases published the same day (hugo-mcp v1.9.0, mcp-oauth-proxy v2.1.0, mcp-installer v1.3.0). Every component of the MCP ecosystem hardened in one day. Full technical recap: MCP security sprint delivered: v1.9.0, 10 chantiers, hardened ecosystem.

This page stays published as an archive — to show the trajectory of an announced sprint, then kept. All original content below is preserved.

Original status (pre-delivery)

This page publicly documented an ongoing hardening sprint on arleo.eu’s MCP infrastructure. For security reasons, specific details of each chantier were not exposed until fixes were delivered (“sec-first” philosophy: don’t publish an attack roadmap).

Why this transparency

I debated whether to publish this page. Arguments for transparency:

• Public commitment = healthy pressure on yourself to deliver
• Documentation of a homelab whose goal is to learn and share
• Honesty with readers consuming other technical articles

Arguments against:

• Attack roadmap: if I precisely list what’s not yet protected, I give clues to a patient attacker
• Artificial pressure: announcing a sprint then not delivering = worse than announcing nothing

Adopted compromise: publish the direction and hardening domains without specifying what’s weak today. Specific technical detail published on delivery.

Sprint scope

The sprint covered 10 chantiers grouped into 4 domains:

1. Application hardening (FastAPI + Pydantic)

Reinforcement of MCP entry layers: strict input validation, unified error handling, no information leak in responses (stack traces, internal paths, lib versions).

2. Authentication and tokens

Refactor of MCP access token management: lifetime, rotation, revocation, hashing in storage. Allow cutting off a compromised client’s access without redeploying the service.

3. Observability and audit

Integration of JSON structured logs ingested in BetterStack via Vector. Each MCP call must produce a traceable event: who, what, when, duration, status. Enables anomaly detection in near real-time.

4. Infrastructure and resilience

TLS for internal traffic between NUC and VM, dedicated ModSec rules on the /mcp path, disaster recovery runbook (token theft, server compromise, data loss).

What was already in place before the sprint

To not create false impressions, here are the layers already in place on infrastructure before the sprint (so out of scope):

• nginx + mandatory TLS 1.3 (Mozilla Modern config)
• Cloudflare WAF + Bot Management + IP whitelist
• ModSecurity + OWASP CRS 4.x on all vhosts
• CrowdSec in WAF mode + Cloudflare bouncer
• systemd hardening at level 1.7 (cf. systemd hardening)
• HMAC validation on webhooks
• Frontmatter Pydantic validation (1 chantier of 4 in the validation category)

The sprint aimed to complete this base, not replace it.

Method

For each chantier:

1. Implemented locally + unit tests
2. Validated on mcp-test-vm (pre-prod VM)
3. Deployed to prod only after passing tests
4. Structured JSON audit log for deployment traceability
5. Post-mortem or technical write-up published after delivery

No direct prod deployment without pre-prod step.

Published releases

TL;DR

systemd-analyze security is an underused tool. It scans your unit files and computes an exposure score from 0.0 (UNSAFE) to 10.0 (PERFECT). Custom Python services often score around 9.6 by default — that’s bad.

I took my hugo-mcp service (FastAPI exposing 7 MCP tools) from 9.6 → 1.7 without breaking a single feature. Here are the directives that actually matter, and the ones that are traps.

Initial score