What your page source says when you're not looking: internal hosts, dev notes, emails

Open the page source of something you shipped and read it like a stranger would. Not the rendered page, the actual served HTML and the JavaScript behind it. Most of it is exactly what you expect. Scattered through it, on a lot of sites, are things you didn't mean to publish: an internal hostname, a comment a developer left at 2am, a list of email addresses sitting in plain text.

None of these is a credential. None of them gets anyone in by itself. They're the low-severity, tidy-your-surface findings, and they matter for a quieter reason: they hand an attacker context, and they hand spammers a mailing list, all from the source you serve to everyone.

The three things that leak into source

These are different leaks with one thing in common: they were written for an internal audience and then shipped to a public one.

Internal hostnames and IPs show up when a reference to your private infrastructure makes it into client code. A 10.0.x.x or 192.168.x.x address, a localhost:8080 left in from local dev, an api.internal.yourco.com or a something.svc.cluster.local Kubernetes service name. Each one tells an attacker about the shape of your network behind the public face: what services exist, how they're named, what's worth trying to reach. Developer comments are notes left in the HTML that were never meant to ship: a <!-- TODO: remove before launch -->, a <!-- staging password is... -->, a <!-- FIXME: this endpoint has no auth yet -->. They're written candidly because the author assumed nobody would read them, and they often point straight at the soft spots. Email addresses in bulk are the spammer's prize: three or more distinct addresses sitting in the page source is a harvestable list, and bots that do nothing but scrape mailto: and plaintext emails will take it.

Why low-severity intel still matters

The instinct is to ignore these, because individually they're harmless and the report marks them low or info. That's the right severity and the wrong conclusion. Reconnaissance is the expensive part of an attack, and these findings subsidize it.

An internal hostname in your JavaScript tells an attacker that api.internal.yourco.com exists, which is a target they didn't have a minute ago. A comment admitting an endpoint has no auth tells them exactly where to point their first request. A staging URL left in a fetch() call points at an environment that's often less hardened than production and sometimes shares its database. None of these breaks anything on its own, but they turn "probe blindly and hope" into "go straight to the weak spot," and an attacker who finds three of them on your page has a head start you gave them. This is the granular, in-the-source version of everything passive reconnaissance collects about you: the same principle, applied to the strings inside the files rather than the files themselves.

Clean it up at the build, not by hand

The fix is to stop shipping internal-only content to the public bundle, and the durable way to do that is in the build, not by hoping you catch it in review.

// app.js, served to everyone
const API = "https://api.internal.yourco.com";  // internal host
fetch("https://staging.yourco.com/v1/data");     // staging URL
// <!-- TODO: /admin still has no auth, fix before launch -->
// contact us: [email protected], [email protected], ...

Configure your production build to strip comments (most minifiers do this with a flag). Keep internal hostnames and IPs out of client code by sourcing API URLs from server-side config rather than hardcoding them in the bundle. Route requests through your own domain so private hostnames never appear client-side. And replace bulk plaintext emails with a contact form or, at least, obfuscated addresses, so the page isn't a ready-made list. These are conservative, low-priority fixes, and the report treats them that way; they're hygiene, not emergencies.

What your served HTML and JavaScript say about your internals is, by definition, readable by anyone, because it's the source you hand to every visitor, and that's the read SurfaceCheckr does. It scans the HTML and scripts you serve for private IPs and internal hostnames, for comments with developer phrasing that signals a leftover, and for harvestable clusters of email addresses, then aggregates them per type so you get a tidy list instead of a flood. We read what's in the source and stop; we don't try to reach the internal hosts we find or act on what a comment admits, because that would cross from passive into active and we don't. The list is the point. It's the stuff you'd want to clean up before someone else reads it as a map.