Consumer Wallet Organization Slug Enumeration Automation: When a 404 Answers a Question Nobody Asked It To

A URL that returns a different status code depending on whether some value exists is a very common, very natural web pattern — and it silently becomes a disclosure the moment the value being checked is itself something worth knowing, independent of whatever content the URL would otherwise show. Whether a specific company is a customer of a specific vendor is exactly this kind of value: unremarkable on its own, but not something every business wants trivially discoverable by a stranger typing guesses into an address bar, and not something a vendor should make discoverable without anyone deciding that it should be.

Centriu Loop's public consumer portal lives at a URL that names the specific business it belongs to by a short, human-readable slug the business itself chose — a natural, ordinary design for a public-facing page meant to be shared with that business's own customers. Before this fix, the page's own logic used that slug as part of deciding what to do: it queried the organizations table directly to confirm the slug corresponded to a real, registered Centriu Loop customer before proceeding.

That lookup, entirely reasonable as an implementation detail, had a side effect visible from outside the system entirely: a slug that matched a real organization let the request proceed to the portal itself, returning an HTTP 200 status. A slug that matched nothing returned a 404. Nothing about the portal's actual CONTENT was exposed in either case to someone without valid consumer credentials — but the STATUS CODE alone, which any browser or simple script receives automatically on every request, was enough to answer a specific, real question: is this company a Centriu Loop customer? A stranger could work through a list of company names, converting each into its likely slug format, and learn — with nothing more than ordinary web requests, no login, no special tooling — exactly which ones came back 200.

The underlying pattern is a common one specifically because it looks so unremarkable in isolation: checking whether a referenced record exists before proceeding is a completely standard piece of authorization logic, and 404-for-missing/200-for-found is the conventional, expected behavior for almost every other kind of URL on the web. The defect here was not the pattern in general — it was applying that pattern to an identifier whose mere existence-or-not is itself a fact some businesses would reasonably prefer not to be a public, machine-checkable signal, especially machine-checkable at zero cost and with no way for the affected business to know it had happened.

The fix removes the slug from the portal's authorization decision entirely, rather than trying to rate-limit or obscure the difference. The page no longer performs a lookup against the organizations table using the URL's slug as a search key at all — the slug plays no role in determining whether the request is authorized to proceed. Every address, whether it happens to match a real organization's slug or an arbitrary invented string, now returns the identical HTTP 200 status and renders the identical initial screen, which itself requires the separate, actual credential (covered on a companion page) before revealing anything at all. The question "does a company with this name use Centriu Loop" is no longer one the public URL structure can answer, for any input.

Before the fix, someone curious whether a specific, named competitor used Centriu Loop could construct a plausible slug from that company's name, request the corresponding portal URL, and learn the answer directly from whether the response was a 200 (yes) or a 404 (no) — a single, unauthenticated web request, repeatable for any number of company names, with no trace distinguishable from ordinary traffic. After the fix, the identical request returns 200 regardless of the slug, disclosing nothing about which businesses are Centriu Loop customers through the URL structure itself.

Centriu Loop's public consumer-portal URL no longer functions as a means of discovering which named businesses are Centriu Loop customers — every address responds identically regardless of whether its slug corresponds to a real organization, closing a public, unauthenticated enumeration path that required no login and no special tooling to use.

This automation governs the internal authorization logic behind Centriu Loop's own public consumer-portal URL — it does not change how a business chooses, is assigned, or shares its own slug, does not add a customer-facing setting, and does not affect any OTHER Centriu system's own use of a slug in its URLs, which this fix does not touch.

Returning 404 for a URL segment that does not correspond to a real record is the ordinary, expected behavior across most of the web, and is usually the right choice — the risk is specific to a case where the very fact of a match is itself information someone has a reason to keep from being trivially, publicly checkable. Designing a public-facing route so that its response code depends only on whether a genuine credential is later presented — never on whether an identifier in the URL happens to correspond to something real — removes the question of existence from the URL's own observable behavior entirely, at the cost of a slightly less conventional 404 policy for that one specific route.