When a 403 Is Good News

Request volume is not readership

At first glance, the traffic numbers looked impressive. Then the paths started telling a different story.

Requests were hitting paths like /.env,/.env.production, /backend/.env, and /config.env.

That is not a crowd of enthusiastic readers. That is automated scanning looking for secrets, credentials, configuration files, and bad deployments.

Read the noise before you react to it

Browser, operating-system, and country charts can look surprisingly normal even when bots dominate the traffic. A scanner can claim to be Chrome on Windows just as easily as a real person can use Chrome on Windows.

The useful evidence was not the headline request count. It was the combination of source addresses, requested paths, status codes, and Cloudflare actions.

Weird traffic does not automatically mean compromise. It means: go look.

Build the narrowest useful rule

Instead of blocking whole countries or playing whack-a-mole with individual IPs, I created a targeted custom rule for the behavior I actually cared about.

The rule matched requests where the URI path contained .envand used the action Block.

Narrow rules are easier to reason about, easier to verify, and less likely to break legitimate traffic.

Verify the control, do not just assume it worked

After deploying the rule, I tested it directly:

curl -I https://nullroutequeen.com/.env

The response was:

HTTP/2 403

Cloudflare then showed the request as a blocked event handled by Custom rules.

That is the part that matters. The rule did not merely exist in the dashboard; it matched the request and blocked it at the edge.

Sometimes a 403 is exactly what you wanted

A 403 is usually something users complain about. In this case it was proof that the security control worked exactly as intended.

The lesson was simple: investigate the traffic, identify the behavior, build the narrowest useful control, and verify the result.

Security gets a lot less spooky when the evidence gets to talk first.