A live payment key sitting in your JavaScript. Files you never meant to
upload. A setting that quietly keeps you out of Google. These are the
checks a senior engineer runs before launch — and not one of them is
visible from a browser.
No account · No card · Nothing stored
Readynothing stored
Is the site actually finished?·homepage, 404s
Is the padlock real everywhere?·TLS, HTTPS, www
Can another site hijack yours?·HSTS, CSP, cookies
Can Google actually see it?·robots, noindex
Does it look right when shared?·title, social cards
Can someone email as you?·SPF, DKIM, DMARC
Is a key in the JavaScript you serve?·in report
Is a key committed in your repo?·code check
Are your dependencies vulnerable?·code check
Did you upload more than the site?·once verified
42
Checks
~1s
Free scan
$29
Full report
0
Accounts
01What catches people
The model wrote your app. It never saw
how it got deployed.
None of these are bugs in your code. They are defaults
nobody turned off, and files that rode along with the upload.
Critical
A live key in your bundle
A publishable Stripe key belongs in your JavaScript. The
secret one looks almost identical and moves money. We read what your site
actually serves and match the shapes of real credentials —
sk_live_, AKIA…,
Supabase service roles, private keys.
Critical
Files you never meant to publish
Upload a project folder and the hidden files go too. A
.git directory makes your whole repository
downloadable — every version, every past commit. A
.env is a text file anyone can request by name.
Nothing links to them, so browsing your own site will never find them.
High
Invisible to Google since launch
Templates ship with noindex and
Disallow: / because they were written for a site
that wasn't finished. Your site works, your analytics stay empty, and
nothing reports an error — the instruction is being followed exactly.
High
Broken where you can't see it
Debug mode prints your file paths and config to anyone who
hits an error. Source maps publish your original source. Console errors and
failed requests mean something didn't load — and no visitor will ever tell
you.
None of it is
visible from a browser. The site loads, nothing is slow, no warning
appears. The failures that cost you most look exactly like everything working.
02What you actually get
Every finding says where it
stops.
Most tools try to sound like they cover more than they
do. Every finding here carries the same four things — what we saw, how the
mechanism works, what it does not prove, and the
change that fixes it. The third one is the reason to believe the other
three.
A scanner that overstates is easy to build and
impossible to trust: once you catch it claiming one thing it did not check,
you have to re-examine everything else it told you. This is a real finding,
from a real scan.
HighLAUNCH-01 · v1
The homepage tells search engines not to index it
Observed
<meta name="robots" content="noindex, nofollow">
Field
launch_noindex_via_meta = true
Detected stack
next
How this works. A
<meta name="robots" content="noindex"> tag
instructs compliant search engines to exclude the page from their index. A
page carrying it is served normally to visitors and omitted from search
results. It is commonly set globally in a staging environment and inherited
by production.
What this does not prove. Nothing about whether
it is intentional. Staging sites, client previews and internal tools carry
this tag on purpose. This records that the directive is present on the
homepage served to a public request.
How to fix it — written for next
In Next.js this is usually the robots key of
the exported metadata object, or a
robots.ts route. Check for
NEXT_PUBLIC_ environment flags gating it, and
confirm the production environment sets them.
01HighThe homepage tells search engines not to index it
02MediumA path that does not exist returns HTTP 200
03MediumNo Content-Security-Policy header is sent
04MediumThe domain publishes no SPF record
05MediumThe domain publishes no DMARC record
There is no score.
A number out of a hundred would be a claim we cannot defend — it implies a
standard nobody published and averages away the one finding that matters.
You get an ordered list and the reason for the order.
And the checks that passed
TLS certificate
✓passed
valid · 83 days left
HTTPS enforcement
✓passed
301 → https
Secrets in bundle
✓passed
0 found
Source maps
✓passed
not reachable
Content-Security-Policy
!finding
absent
DMARC
!finding
no record
A check that could not
run is listed as exactly that — never folded into "nothing found".
And proof it wasn't edited later
Combined hash
a4f1…c72b
TSA serial
116501515
Timestamped
RFC 3161
Every scan is hashed
and timestamped by an independent authority. The report prints the
openssl command that verifies it — against the
issuing authority, not against us.
03What arrives
Three things, and you keep all of them
Screenshots of the real thing — not mock-ups. This is a
genuine scan of example.org.
digitaltrustpass.com/preflight/r/…
The report.
Every finding gets the same four things: what we saw, how it works, what it
does not prove, and the change that fixes it — for your stack.
digitaltrustpass.com/preflight/verify/…
A public address
for it. Send the link to anyone and they see the same record — with
a timestamp they can check against the issuing authority, not against us.
2 changes on example.org
With monitoring
And an email when something moves
Only when something has actually changed. A header that
disappeared on deploy day, a certificate with eleven days left, a key that
appeared in a bundle that did not have one last week.
Silence is the normal state. That is the point of it.
04Why it can't be edited afterwards
Including by us
A report is only worth anything in an argument if the
person reading it doesn't have to take the word of whoever wrote it. So the
record is built to be checked against someone else. Here is the whole
mechanism — it is public, and none of it is ours.
Hashed as it arrives
Every response is hashed at the moment it is
received, not reconstructed from a summary afterwards. Each record is then
linked to the one before it — its hash is computed over the previous link,
its own response hash, and its position in the sequence.
One hash for the run
Those records combine into a single hash for the
whole scan. Alter one observed value later and that record's hash changes,
every link after it stops recomputing, and the combined hash no longer
matches the one that was sent away.
Signed by someone else
The combined hash goes to an independent
timestamping authority under RFC 3161 — the same mechanism used for signed
documents. It returns a token countersigning the hash and the time. The
signing key is theirs. We cannot issue one and cannot alter one.
Your report prints the
openssl command that checks the token — against the
authority's certificate, not against anything we host. If we changed a single
character of a finding afterwards, that check fails.
What the timestamp does not prove. That
the scan was right. It proves this report existed in exactly this form at
that time and has not been altered since — which is a smaller claim, and the
only one the mechanism actually supports.
05The second checkpoint
Everything above is your site. None of it is
your code.
A key in a server-side file never reaches a browser,
so no scan of your deployed site can find one. Nor can it tell which package
versions you actually installed. Upload your project with the report and we
read both — including your full git history, where a key you "removed" in a
later commit is still sitting in every clone.
Critical
Keys that are still in the history
We read the working tree and every past commit, then say
what the key opens — a database, an account, or a card. A Stripe
publishable key belongs in your JavaScript and we will not call it a leak;
a Supabase service_role key looks identical and
bypasses every row-level rule you wrote. The difference is the whole
finding.
High
Dependencies with known holes
The model pinned whatever versions it was trained on, and
they have aged since. We check yours against the public vulnerability
databases and separate what ships to production from what only runs at
build time — because a flaw in a test runner is not the same emergency as
one in the code you serve.
What we found when we tested this.
We ran it against twelve real projects built with Lovable, Bolt, v0 and
Cursor before building it.
Every project whose dependencies could be
resolved carried a known vulnerability — several critical. One had a
database key committed to its history. None of it was visible from outside
the site. Four had no lockfile at all, which we report as
not tested, never as clean.
Your upload is
deleted the moment the scan finishes. Findings record a file, a line and a
digest — never the credential. We never use a key we find to test whether it
still works: that would be both a use of your credential and a way to run up
the bill we are warning you about.
06And the rest of the list
42 checks, one scan
TLS validity and expiryHTTPS enforcementSecurity headersMixed contentCookie flagsapex + www certificateMobile viewportTitle, description, social cards404s that return 404Broken internal linksFramework starter pagesThird-party services and cookiesSPF, DKIM, DMARCSubdomain takeoverPrivacy policy
Every finding says what
we observed, how, what it does not prove, and the specific change that
fixes it — for your stack, where we can identify it.
.env and .env.production.git — is your repo cloneable?Cloud credential filesOpen admin surfacesDirectory listingDatabase ports open to the internet
08Being straight with you
Some of this you can get free
Headers, TLS, cookies
securityheaders.com, SSL Labs and Mozilla
Observatory do this well, and for free. We check the same things
in one pass — we didn't invent them and won't pretend otherwise.
noindex and robots
Lighthouse flags these, and it's already
in your browser's devtools. If you've run it against the deployed site,
you may know already.
Secrets in your bundle
None of them read the JavaScript you serve looking for
the shapes of live credentials. This one is ours.
Keys and dependencies in your code
GitHub does this free — secret
scanning, push protection and Dependabot — and if your project lives
there with those switched on, use them. What we add is for everyone
else: no GitHub account needed, a plain answer about what each key
actually opens rather than a raw alert list, and the result recorded in
the same timestamped report as everything above.
Unlinked files on your server
Structurally impossible for them — probing for
.env needs proof the site is yours, and none of
them have it. This one is ours.
So three of the five are
genuinely available free, and if your site is small and you have the afternoon,
go and get them. What you're buying here is one scan instead of four, an
ordered list instead of four dashboards, a fix per finding — and the two rows
nobody else can do.
09Pricing
Cheap enough to not think about
Free scan
$0
How many findings you have, and how serious. Doesn't
name them.
Launch report
$29
Two checks, not one. Your deployed
site, and — when you upload it — your project's code and full git history:
committed keys, and dependencies with known vulnerabilities. Every finding
named, ordered, with the change that fixes it. PDF, timestamped. No
account.
Or $89 a year. Weekly re-scan, and an email only when
something actually changed. You don't check the locks once — you check them
every time you leave.
Preflight observes your site from the outside on one
date, plus — with your proof of ownership — a short list of specific files.
It is not a penetration test. It does not read your source, log in as anyone,
or send a payload. A clean report is not a guarantee that your site is
secure — it means these named checks found nothing today, and every
report lists exactly what was and wasn't checked.
