Public company materials can reveal more about how an organization operates than their authors intend. In a first-person DEV Community article, Dhruv Malaviya describes reviewing his company’s published materials without credentials or insider knowledge—and finding operational clues in documentation, job listings, configuration examples, talks, and a customer-facing error. His account is a practical prompt for companies to review what they publish, not an independently verified security assessment.
What public-only company reconnaissance can reveal
Malaviya describes a quarterly review lasting about twenty minutes. Those figures describe his own routine, not a recommended industry standard or a measured security result. The exercise focused on material the organization had made public; it did not require access to company systems.
In his account, a README architecture diagram named services, queues, and workers. A screenshot in a support thread exposed an internal hostname and a stack path in a customer-facing error. A 2023 conference talk showed a simplified architecture diagram that he said was still mostly accurate. He also found technology names—including Kafka, Datadog, Auth0, and Terraform—in job listings, and third-party integration variable names in an .env.example file.
These examples illustrate different kinds of clues, not proof of a vulnerability. A job listing can suggest technologies or areas of work, but does not establish that a company is dissatisfied with a vendor or plans to replace it. An environment-variable name can indicate the shape of an integration without revealing a secret value. The useful question for a publisher is whether each detail serves its intended audience enough to justify making it public.
#1 Best Overall
Which public materials deserve a review?
Review only materials your organization has published or is authorized to assess. The aim is to inspect publication choices—not to access systems, probe infrastructure, or attempt exploitation.
- Documentation and README files: Look for internal hostnames, network ranges, vendor names, and detailed stack or topology information.
- Configuration examples: Check
.env.exampleand similar templates for live endpoints, credentials, integration names, or comments that expose unnecessary operational detail. - Job listings: Consider whether named tools and descriptions of operational responsibilities reveal more than candidates need to understand the role.
- Search results and company pages: Search the product name with terms such as “architecture,” and inspect diagrams published on the company site.
- Talks and public posts: Review conference presentations and blog posts, including older material whose architecture details may remain current.
- Customer-facing errors: Inspect screenshots and examples for internal names, file paths, stack traces, or other details that were not intended for customers.
Keep the public manual useful without publishing the internal map
Customers need documentation that explains product behavior, interfaces, and examples. That is different from internal topology, naming conventions, runbooks, and vendor wiring. Malaviya describes the distinction as the “manual” versus the “map”: publish the information people need to use the software, while limiting operational material to appropriate internal audiences.
This is a publication decision, not a scoring framework. For each detail, weigh its usefulness to a customer or candidate against its potential value to an outsider. Where operational material is genuinely needed for work, use access controls and review rather than treating every document as public by default.
Return safe errors; keep diagnostics in logs
An error response can accidentally document the system. The support screenshot in Malaviya’s account showed an internal hostname and stack path. A safer pattern is to return a concise, generic message and a reference ID to the user, while retaining detailed diagnostics in logs for authorized responders.
Rank #3
This separates two needs: users need to know that something went wrong and how to refer to it; support and engineering teams need diagnostic context. Avoid returning internal hostnames or stack traces simply because they make a failure easier to diagnose in the moment.
Make configuration examples genuinely generic
Configuration templates should teach the required shape of a setting without acting as an inventory of live infrastructure. Use generic variable names where possible, blank or clearly illustrative values, and comments that explain purpose rather than disclose real endpoints or credentials. Even without secret values, a list of vendor-specific integration names may reveal more about the stack than the example needs to.
The same principle applies to hiring materials: describe capabilities—such as event pipelines, observability, or authentication integrations—when naming a particular vendor adds little value to the candidate’s understanding of the role.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Publication hygiene complements security controls
Malaviya explicitly frames documentation discipline as one layer, not a substitute for technical boundaries. Network controls, scoped secrets, and access controls still matter; his article does not audit whether any particular organization has implemented them effectively.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Best Value
Public material can also be copied or mirrored, so removing a page cannot guarantee that every copy disappears. The practical goal is to make publication deliberate and avoid adding fresh operational detail unnecessarily. As Malaviya puts it, “Errors are involuntary documentation.”
What the account does—and does not—establish
The source is Dhruv Malaviya’s first-person DEV Community article, not a controlled security study or an independent assessment of a named company. It reports the author’s observations and recommendations, but provides no measured breach-likelihood reduction, risk estimate, or general result for the twenty-minute quarterly routine. Its value is as a concrete checklist for reviewing published materials, not as evidence that publication review alone prevents attacks.
Source: Dhruv Malaviya, “I Did Recon on My Own Company , Using Only What We Published,” DEV Community.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute
