I was working on a technical post about DNS resolution when I encountered something unexpected. Every time I typed the path to the hosts file (/etc/h*sts – intentionally obfuscated to avoid triggering the very issue I’m discussing), my Substack editor would display a “Network Error” and fail to autosave my draft.

At first, I assumed Substack was experiencing an outage. However, their status page showed all systems operational. Something else was happening.

I noticed this error appeared consistently when I typed that specific file path. But when I wrote variations like /etc/h0sts or /etchosts, the editor worked fine. Curious about this pattern, I tested more system paths:

Path                  Result
/etc/h*sts            ❌ Error
/etc/h0sts            ✅ Works
/etchosts             ✅ Works
/etc/pass*d           ❌ Error
/etc/password         ✅ Works
/etc/ssh/sshd_conf*g  ❌ Error
/etc/ssh              ✅ Works
/etc/h*sts.allowed    ❌ Error
/etc/h*sts.foo        ❌ Error

(Note: the * is used to replace the actual character in the paths that result in an error)

A pattern emerged: paths to common Linux system configuration files were triggering errors, while slight variations sailed through.

Looking at the browser’s developer tools revealed something interesting:

The editor was making PUT requests to Substack’s API to save the draft, but when the content contained certain system paths, the request received a 403 Forbidden response.

The response headers showed that Cloudflare was involved:

Server: cloudflare
Cf-Ray: 935d70ff6864bcf5-ATL

This behavior points to what’s likely a Web Application Firewall (WAF) in action. But what’s a WAF, and why would it block these paths?

Think of a Web Application Firewall as a security guard for websites. It sits between users and the web application, examining all traffic and blocking anything suspicious.

Like a nightclub bouncer who has a list of troublemakers to watch for, a WAF has rules about what kinds of requests look dangerous. When it spots something on its “suspicious list,” it rejects the request.

One common attack that WAFs defend against is called a “path traversal” attack. Here’s a simple explanation:

Imagine your website has files organized in folders, like:

/images/profile.jpg
/docs/report.pdf

A hacker might try to “break out” of these folders by sending requests like:

/images/../../../etc/pass*d

This is an attempt to navigate up through directory levels to access sensitive system files like the password file on the server.

System paths like /etc/h*sts and /etc/pass*d are common targets in these attacks because they contain valuable system information. A hacker who gain