admin 0.0.0.0:2019 lets anyone who can reach port 2019 replace your whole Caddy config with no password, and a file_server with no root serves the folder Caddy runs in, .git and .env included. This skill finds those and ten other Caddy config mistakes before you reload or deploy, and tells you how to fix each one.

Your agent runs a scanner on your project: files named Caddyfile (also Caddyfile.prod and similar), .caddyfile and .caddy, and Caddy JSON configs. It reads Caddyfile syntax the way Caddy does: the global options block, snippets and import (also of other files in the folder, so import sites/*.caddy is followed), several addresses per site, a single site without braces, matchers, comments, quoted strings, heredocs and {env.*} placeholders. It follows Caddy's real defaults: the admin API on localhost:2019, no security headers and no HSTS unless you add them, the active Caddyfile hidden from file_server but other dotfiles not. The minimal Caddyfiles from the Caddy documentation and the Docker image's default Caddyfile pass clean. It never runs Caddy or calls its admin API. It returns BLOCK, REVIEW, or NOT FLAGGED, with the file, line, reason, and a safer approach. Secrets are never printed.

What it checks

BLOCK (fix before shipping)

• C01: the admin API on :2019, 0.0.0.0, a LAN IP or a host name instead of localhost or a unix socket

• C02: tls_insecure_skip_verify on a reverse_proxy backend, and insecure_secrets_log

• C03: file_server on /, /etc, /var, a home folder, a .ssh folder or Caddy's own certificate storage

• C04: DNS provider tokens, API keys, passwords, EAB keys and Authorization headers written in the config

REVIEW (check before release)

• C11: tls internal, local_certs or a staging ACME CA on a public domain

• C12: http:// or :80 public sites that serve content, and auto_https off

• C13: file_server with no root or root . while nothing hides .git and .env

• C14: CORS that copies any Origin into Access-Control-Allow-Origin with credentials allowed

• C15: a public site without the security headers the other sites in the config send

• C16: trusted_proxies set to 0.0.0.0/0 or ::/0

• C17: log_credentials, which writes cookies and Authorization headers to the access log

• C18: protocols tls1.0 or tls1.1, which Caddy v2 does not support and refuses to load

What's included

• The scanner (Python 3.9+, standard library only)

• A rules guide with the reason and safer approach for each rule

• A risky and a safe example project (a Caddyfile with imported site files and a Caddy JSON config), and the real report the scanner produces on the risky one

Limits

It reads the config files as written. Values from environment variables (CADDY_ADMIN, {env.*}), command-line flags, config pushed through the admin API, caddy-docker-proxy labels and imports of files outside the scanned folder are not checked, and headers sent by the app behind reverse_proxy are not visible to it. NOT FLAGGED is not a guarantee.

Contents

One ZIP file with 15 files: SKILL.md, the scanner in scripts/ (4 Python files), references/rules.md (every rule with its reason and safer approach), and examples/ (8 example files plus report.md, the real scanner output on the risky example).

How to use: This is an agent skill: a folder with a SKILL.md file and Python scripts that an AI coding agent such as Claude Code, Cursor, or Codex CLI can run. Unzip it into your agent's skills folder (for Claude Code: ~/.claude/skills/), then ask your agent to check your project. The scripts also run on their own with Python 3.9 or newer, with nothing to install. They read your files only: no network access, and nothing is sent anywhere.