Security - Tag - arleo.euhttps://www.arleo.eu/en/tags/security/Security - Tag - arleo.euHugo -- gohugo.ioenThu, 28 May 2026 23:45:41 +0200CSP 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.

]]>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.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:

]]>MCP security sprint delivered: v1.9.0, 10 chantiers, hardened ecosystemhttps://www.arleo.eu/en/posts/sprint-securite-mcp-livre/Sat, 09 May 2026 18:44:12 +0200Jmrhttps://www.arleo.eu/en/posts/sprint-securite-mcp-livre/

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

# Chantier Implementation
C1 Rate limiting slowapi, 60 req/min per IP
C2 Token rotation tokens.json + token_mgr.py CLI
C3 JSON audit logs structlog, machine-readable events
C4 Strict Pydantic v2 CreatePageArgs / UpdatePageArgs with constraints
C5 bcrypt cost-12 Tokens hashed in storage
C6 NUC ↔ VM TLS EC P-256 cert, uvicorn SSL, proxy verifies the cert
C7 requirements.lock SHA-256 hashes via pip-compile --generate-hashes
C8 Info disclosure Docs off, generic exception handler, proxy_hide_header
C9 nginx WAF POST + application/json enforcement on /mcp, OWASP CRS active
C10 Backup DR backup.sh GPG-encrypted, 30-day retention

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

]]>Roadmap: MCP Security Sprint — 4 domains, 10 chantiers (DELIVERED ✅)https://www.arleo.eu/en/posts/roadmap-sprint-securite-mcp/Sat, 09 May 2026 13:07:33 +0200Jmrhttps://www.arleo.eu/en/posts/roadmap-sprint-securite-mcp/

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

]]>systemd hardening: taking a Python service from 9.6 to 1.7https://www.arleo.eu/en/posts/hardening-systemd-mcp/Sat, 09 May 2026 13:02:29 +0200Jmrhttps://www.arleo.eu/en/posts/hardening-systemd-mcp/

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

]]>From 46 Hashes to Zero: Migrating CSP to Dynamic Nonceshttps://www.arleo.eu/en/posts/csp-nonce/Wed, 15 Apr 2026 13:22:00 +0200Jmrhttps://www.arleo.eu/en/posts/csp-nonce/

⚡ In short

The original CSP listed 46 SHA-256 hashes to cover inline scripts and styles — unmanageable, fragile, and approaching Cloudflare’s 4,096 character limit. This migration to dynamic nonces reduces the CSP to ~600 characters, eliminates all manual hash maintenance, and adds structured violation reporting in BetterStack.

The Grav plugin powering this is available on GitHub: 🔌 Plugin : jmrGrav/grav-plugin-csp-nonce

🧠 Why

When implementing a strict Content Security Policy on a Grav CMS site served through Cloudflare, the naive approach is to list SHA-256 hashes for every inline script. It works, but quickly becomes unmanageable. Several compounding problems:

]]>