Back to All posts
Production incident9 Jun 20262 min read

How Production Endpoint Probing Changed Our Backend Security Thinking

Production logs started showing requests to routes that did not exist in the app. The probes targeted common paths like /api/.env, /api/openapi.json, /api/graphql, and similar patterns, all returning 404.

Node.jsExpress.jsAPI securityunauthorized requests

1 like · 2 views

The Problem

The backend started receiving requests for API routes that were never built. The screenshot shows anonymous GET requests to paths like /api/v1/.env, /api/v2/.env, /api/.env, /api/graphql, /api/account, /api/openapi.json, /api/env, /api/v1/config, and /api/v2/settings. These requests were returning 404, but they made it clear that something was probing the app’s public surface.

API security
These requests were returning 404, but they made it clear that something was probing the app’s public surface.

Root Cause

Nothing was broken in the app itself. The issue was that external traffic was guessing common backend route patterns to see what existed. The requests were not meant for the product’s actual features; they were probes looking for sensitive files, documentation endpoints, or predictable API structures. That was not obvious at first because the app was functioning normally, and the only signal came from the security logs.

Investigation

At first, the traffic just looked random. The useful clue was the repeated pattern: requests were not scattered by accident, they were targeting common paths developers often expose by default. Seeing endpoints like openapi.json, graphql, and .env requests made it clear the traffic was exploratory, not user-driven. The 404 responses confirmed those routes were not present, which was good, but the pattern still exposed how predictable backend route naming can attract unwanted probing.

Solution

The practical response was to treat the logs as a security signal and review what the backend exposes publicly. That means keeping sensitive routes out of predictable locations, avoiding unnecessary public endpoints, and continuing to return 404 for routes that do not belong in the product. It also helps to keep monitoring in place so similar probing patterns can be spotted early.

The log already shows a useful defense: the endpoints were not available, and the app returned 404. The main takeaway is not that the app was compromised, but that the route structure should be reviewed with production traffic in mind.

Key Takeaways

  • Production traffic includes bots and scanners, not just real users.

  • Predictable endpoint names attract probing.

  • .env, openapi.json, graphql, config, and settings are common targets.

  • Returning 404 for non-existent routes is good, but logging them still matters.

  • Endpoint design is part of backend security, not just API organization.

  • Security monitoring can reveal patterns you would never notice locally.

OR
Oodo Roland
Fullstack engineer. I build and deploy production systems and write about what breaks along the way.

Found this useful? Pass it on.

Share
Read next
How Production Endpoint Probing Changed Our Backend Security Thinking | Oodo Roland