Writing "/etc/hosts" breaks the Substack editor

Original Article ↗ Hacker News Discussion ↗

What Actually Broke Substack

  • Many commenters attribute the bug to a Cloudflare Web Application Firewall (WAF) rule that flags paths like /etc/hosts, /etc/passwd, etc., citing a specific Cloudflare ruleset update and an LFI-related CVE.
  • Others initially caution “correlation ≠ causation,” but point out the author’s systematic testing: only specific Unix file paths trigger 403s, small edits (e.g. h0sts) succeed.
  • A Substack engineer confirms it was an irrelevant Cloudflare managed WAF rule that has now been disabled.
  • Several note this is not a genuine “security vs usability” tradeoff but simply misapplied security: blog post bodies should never be treated as executable input.

How WAFs Work (and Misfire)

  • WAFs generally match simple patterns (substrings, regexes, rule files like OWASP Core Rule Set), often without context about HTTP method, JSON structure, or whether text is command vs content.
  • This leads to “Scunthorpe problem” cases: benign text is blocked because it resembles attacks (e.g. /etc/hosts, SQL-ish strings, code snippets, XSS payloads).
  • Examples from other systems: passwords rejected for containing ', base64 cookies blocked for --, any body containing delete, HTML/JS in LLM prompts blocked at the proxy, and auto-bans when logs or notes contain system(.

Critiques of WAFs

  • Strong anti‑WAF sentiment:
    • Security theater / checkbox for auditors, CISOs, insurers, and RFPs, especially when apps don’t even use SQL or Windows but still must “block 7000 test strings.”
    • Hide real vulnerabilities by masking symptoms, giving teams a false sense of safety and discouraging proper input handling.
    • Add their own attack surface and random, hard‑to‑debug failures, especially on technical sites that legitimately discuss code, paths, or queries.
    • Often imposed by non-technical stakeholders; developers bear the cost.

Defenses of WAFs / Defense in Depth

  • Pro‑WAF comments frame them as:
    • A speed bump that blocks commodity scanners and naive exploit attempts, even if they won’t stop determined attackers.
    • A fast mitigation layer for new critical vulns (e.g. log4j, old WordPress exploits) while underlying software is patched.
    • A way to throttle or shed malicious traffic before it hits origin servers, and to centralize detailed security logging.
  • Even defenders acknowledge high false-positive rates and the need to tune or disable rules for technical content.

Broader Themes and Lessons

  • Compliance, insurance, and large‑org politics frequently drive WAF adoption and rigid password/security policies, even when standards bodies or practitioners consider them counterproductive.
  • Multiple analogies appear: airline shoe screening, spam filters that break normal discussion, and “concrete wall instead of a gate.”
  • Consensus for this case: scanning and blocking blog text for path strings is the wrong layer; proper escaping and application-level security are the right tools.