How LaunchGuard scans, and what it can honestly tell you.
A LaunchGuard AI security audit is a passive external scan. The same engine runs on every scan, free or paid. It reads only what your product already exposes to the public, and it shows its work: what it looked at, where the evidence came from, and where a passive audit hits its limits.
Passive by design
We make ordinary public requests, the kind any browser makes. No attacks, no exploits, no logins. That’s why a scan is safe to run on any site, on any plan, without permission.
Evidence, not opinion
Every finding names the exact data point behind it and carries a confidence level. Thin evidence is marked inferred, never dressed up as a confirmed alarm.
Fixable by the right owner
Each finding says whether it lives in your code, your hosting, or your DNS, so you’re never told to fix something you don’t control.
What we look at
Fourteen categories across the surface a real attacker sees first. Each is scored on its own, then rolled into one Security Health Score.
Transport & browser protection
Security headers
Whether the response carries HSTS, a Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. A CSP delivered by meta tag counts the same as one sent as a header.
TLS & certificate
Certificate validity, expiry, and issuer read from public certificate transparency logs, plus whether HTTPS is actually enforced on the connection.
Cookies & sessions
The Secure, HttpOnly, and SameSite flags on every cookie the site sets, which decide whether a session can be stolen or sent cross-site.
CORS & cross-origin policy
What the server reflects when a foreign origin asks. A policy that echoes any origin alongside credentials would let any website make authenticated requests on a visitor’s behalf.
Exposed data & code
Exposed files & config
Publicly reachable sensitive paths such as environment files, version-control config, database dumps, and backups.
JS secrets & source maps
Leaked API keys and tokens in loaded JavaScript, and source maps that hand out the original source of a supposedly compiled bundle.
Public storage
Openly listable storage buckets referenced by the site, which can expose files never meant to be browsed.
Third-party scripts & supply chain
HTTP content loaded on an HTTPS page, and cross-origin scripts loaded without Subresource Integrity — an unpinned dependency that changes silently if the source is compromised.
API & application surface
API surface & documentation
Publicly reachable API specifications, a GraphQL endpoint that answers introspection to anyone, and whether a security.txt invites coordinated disclosure. A published disclosure policy earns a higher score, not a finding.
Admin interfaces & APIs
Publicly reachable admin panels and undocumented API surfaces, plus whether the app shows any sign of rate limiting or edge protection on its expensive endpoints.
Frameworks & dependencies
The stack fingerprint disclosed in banners and responses, and version signals that point to known-risky or outdated components.
Domain & identity
DNS & email security
SPF, DKIM, and DMARC records and basic DNS posture, which decide whether someone can send mail that looks like it came from the domain. DKIM is checked against the selectors the domain’s actual mail provider uses.
Subdomains & takeover
Subdomains seen in certificate transparency, each checked for the fingerprints of an unclaimed third-party host — a dangling record an attacker could claim and serve content under the brand’s own name.
Brand & domain protection
Lookalike and typo variants of the domain that currently resolve in DNS, which are the raw material of phishing and brand impersonation.
Where the evidence comes from
Every source is public and current. Nothing is cached into staleness, and nothing depends on a vendor database we cannot see into.
01
The live response
Every scan makes ordinary public requests to the target and reads exactly what any browser would: headers, cookies, redirects, the page HTML, and the scripts it loads. This is always current because it is the site as it is serving right now.
02
Certificate transparency logs
Public, append-only logs that every certificate authority is required to write to. We read them for certificate details and for the subdomains a domain has published certificates for. They update continuously as new certificates are issued.
03
Public DNS over HTTPS
We resolve SPF, DKIM, DMARC, MX, and DNSSEC records, and check whether lookalike domains are live, against public DNS. DNS is the authoritative, real-time source for all of it.
04
Maintained fingerprint sets
The takeover fingerprints, mail-provider DKIM selectors, and sensitive paths we probe are curated lists kept in the scan engine and updated as new hosting platforms and patterns appear.
How we keep it accurate
A security report is only as useful as it is trustworthy. False alarms are a failure, and so is a harsher scan for people who pay. We designed against both.
Evidence before verdict
Every finding names the exact data point that triggered it. If the evidence is thin, the finding is marked inferred rather than confirmed, and it is weighted accordingly. We would rather under-claim than raise a false alarm.
We tell you who can actually fix it
Each finding is tagged as fixable in your app code, at your hosting or edge layer, or at your DNS provider. When it is not your code, we say so plainly and give you a message you can paste to the provider, so you are never told to change something you do not control.
Fairness built into scoring
A Content-Security-Policy set by meta tag scores like a real one. DKIM is checked against your mail provider’s real selectors, not a guess, so valid email security is never reported as missing. A clean signal scores high — the absence of a problem is a good result, not a reason to invent one.
The same engine, every time
The score you see on a free scan is produced by the exact engine behind Verify and continuous Monitor. There is no separate, harsher scan for paying customers. Re-scan and the number moves only because your posture moved.
The honest limits
What a passive scan cannot see
A passive scan only reads what a system exposes to the outside world. It never attacks anything, which is exactly what makes it safe to run on anyone’s site, on any plan, without asking. The tradeoff: there are things it can’t see, and we’d rather say so than let a clean scan pass as a clean bill of health.
—Broken authorization inside your backend — whether one user can reach another user’s data through your API.
—Business-logic flaws that only appear once you are logged in and using the product.
—Vulnerabilities behind authentication, which a passive external scan never crosses.
—The security of code and infrastructure that never surfaces in a public response.
A strong Security Health Score means the exposed surface of your product is in good shape. That’s a real bar, and the right one to clear first. Deeper, authenticated review is a separate discipline. Where a finding points to that kind of risk, the report says so.
How the score works
Every category is scored from 0 to 100 from its own evidence. Those roll up into a single Security Health Score with a letter grade, so a non-specialist can read the result in one number and a specialist can open any category to see why.
A
90–100
Strong. The exposed surface is well configured.
B
75–89
Solid, with a few things worth tightening.
C
60–74
Real gaps that deserve attention.
D
40–59
Significant exposure across several areas.
F
0–39
Serious, broad exposure to address before launch.
A product reaches LaunchGuard Verified at a score of 80 or above, once a Verify re-scan confirms the open issues are resolved. Verified is proof you can hand to a customer or investor that the bar was cleared, not just claimed.
What Verified proves, and what it doesn't
LaunchGuard Verified is a passive external security scorecard: proof that your app scored 80 or above with no open critical or high findings, and that it keeps passing as we re-scan. That is a real, checkable signal you can show a user, a partner, or an investor.
It is not a compliance certification. Verified is not SOC 2, ISO 27001, or NIST, and it is not a penetration test or a source-code audit. It reads what your app exposes to the public, not your backend logic or your repository. We say this plainly so the badge means exactly what it says, no more.
See it run on your own product. The scan is free and takes under a minute.
