Public attack surface scan for production app launches

A public attack surface scan is the fastest way to see what strangers can reach on your production domain before launch. It checks the same paths attackers start with: exposed admin panels, forgotten preview hosts, public files, weak headers, and secrets shipped to the browser. If you do one thing before going live, make it an outside-in review of your internet-facing assets.

When to run a public attack surface scan?

Run it before launch, after major infrastructure changes, and any time you add a new domain, CDN rule, auth flow, or third-party script. The goal is not a giant audit. The goal is a short, external view of what is reachable from the public internet right now.

For most teams, the highest-value scope is small:

Primary app domain and marketing domain
Known subdomains, previews, and old staging hosts
Common admin routes and framework defaults
Public files like backups, config exports, and .env
Browser-delivered code, redirects, and response headers

This kind of attack surface review catches issues internal tests miss because internal tests often assume trusted access. An attacker does not. They enumerate DNS, hit obvious paths, inspect JavaScript, and look for files that should never be public.

If you want a fast baseline, start with a simple security scan and follow it with a deeper external pass on high-risk domains using deep scan. If your app has an admin area or ops panel, review patterns from exposed admin pages as part of that first pass.

Assets that leak first

In real launch reviews, a few categories show up repeatedly. They are easy to miss because the app appears functional while the exposure sits one request away.

The first pattern is staging subdomains. Teams decommission the app but leave DNS, basic auth, or old deployments alive. Those hosts often carry test data, old credentials, or debug endpoints that never made it through current hardening.

The second is public JavaScript bundles. Frontend code regularly reveals API base URLs, internal route names, storage bucket paths, feature flags, and sometimes live keys that should have stayed server-side. If you are auditing browser output, also review common checks for exposed API keys.

The third is misconfigured storage and forgotten files. Build artifacts, SQL dumps, support exports, and /backup.zip still appear in production more often than teams expect. Public .env exposure is usually a critical finding because it can turn a simple file leak into full service compromise. Use targeted public .env checks on every public host.

The last common group is security headers and route behavior. Missing X-Frame-Options, weak CSP, and permissive caching are not always immediate compromise paths, but they lower the cost of later attacks. More urgent is HTTP 200 on hidden paths like /admin, /debug, /swagger, or /actuator. Even when auth blocks the next step, route discovery helps attackers map the app.

A quick external security scan can start with requests like these:

bash

host="https://app.example.com"
for path in "/.env" "/admin" "/swagger" "/api/health" "/backup.zip"; do
  code=$(curl -sk -o /tmp/out -w "%{http_code}" "$host$path")
  echo "$code $path"
done

curl -sk "$host/_next/static/chunks/main.js" | grep -E "sk_live_|AIza|SUPABASE|STRIPE"

This does not replace a full production exposure audit, but it is enough to catch obvious leaks in minutes. Run it against every public hostname, not just the homepage. Forgotten support portals and old marketing subdomains often create the highest-risk findings.

Verify and fix fast

Once you find an exposure, do not stop at the path name. Reproduce every finding with a clean request and confirm what a real outsider can access. A login page at /admin is different from an admin dashboard returning user data. A source map is different from a file containing secrets.

Use a simple triage flow:

Confirm the response from an external network, not your internal VPN.
Check whether the response contains sensitive data, internal routes, or usable credentials.
Rank severity by exploitability, not by how scary the path looks.
Fix the root cause, then retest from outside the perimeter.
Add the path or pattern to your recurring external exposure review.

A few examples help. A public /.env with live credentials is usually critical because compromise can move quickly into databases, storage, or payment systems. An open /swagger page may be medium if it only documents endpoints, but high if it exposes authenticated testing in the browser. Missing headers are often medium or low unless they create a direct abuse path.

The fastest fixes are usually boring and effective: remove public files, disable old subdomains, move secrets server-side, require auth at the edge, and tighten response headers. Avoid patching only the symptom. If a key was ever exposed in browser code, rotate it. If a staging host leaked data, destroy the deployment, not just the DNS record.

This is also where an internet-facing check differs from a scanner that only reports library CVEs. The question is not just, "Is the package old?" The question is, "Can a stranger reach something dangerous right now?" That is the issue that matters most two days before launch.

Checklist before you ship

Use this checklist before ship on the final domain set:

Confirm every public hostname has an owner and a clear purpose.
Test common sensitive paths such as /.env, /admin, /debug, /swagger, and backup filenames.
Review browser bundles for secrets, internal endpoints, and storage paths.
Validate redirects, auth gates, and robots rules do not expose hidden systems.
Check continuous scans after DNS changes, framework upgrades, and deployment pipeline edits.
Rescan after every fix to prove the exposure is gone externally.

A good launch process treats this as a repeatable gate, not a one-time panic task. The highest-value scans happen after last-minute config changes, because that is when CDN rules, env promotion mistakes, and preview leftovers tend to slip into production.

If you only have an hour, prioritize reachable files, secrets in client code, forgotten subdomains, and any route that returns privileged content to an unauthenticated request.

A focused outside-in review gives you a much clearer signal than a long checklist copied from a compliance doc. It tells you what is truly visible, what is exploitable, and what should block launch until fixed.

Faq

How is this different from a normal vulnerability scan?

A normal vulnerability scan often focuses on software versions, missing patches, or known CVEs. An external exposure review focuses on what the public can reach right now, such as leaked files, open admin routes, browser-shipped secrets, weak redirects, and forgotten subdomains. It is closer to an attacker's first recon step.

What should be in scope for the scan?

Include every public hostname tied to the launch, not just the main app. That means root domains, www, API domains, auth domains, status pages, preview deployments, old staging hosts, and file storage endpoints. Most serious findings appear on secondary assets that nobody included in the original release checklist.

How often should i run this kind of check?

Run it before launch, after major infra changes, after DNS or CDN edits, and on a recurring schedule for active production apps. Weekly is reasonable for lean teams, but high-change environments may need daily checks. The key is rerunning after every meaningful change to public exposure.

If you want a fast final pass before release, AISHIPSAFE can help you check the external surface of your app and catch obvious exposures before users, bots, or attackers do.