What an attacker sees in the first hour after you launch

You point the domain at the app, the certificate turns green, you post the link. For you, the launch is a moment. For the rest of the internet, it is an event on a feed, and the feed is read by machines that never sleep. Here is what happens in the hour that follows, from the outside, in the order it usually happens.

Minute 0: the certificate announces you

Before anyone types your URL, the certificate you just obtained is written to public logs. This is by design: certificate transparency is how browsers keep certificate authorities honest, and every certificate issued for a public domain ends up in those logs within minutes. Anyone can subscribe to them. Many do, and not all of them are researchers.

What this means in practice: the moment app.yourstartup.com gets a certificate, its existence is known. So is staging.yourstartup.com if you gave it one. So is the internal admin tool someone put behind a subdomain last week "just for now". The list of things you expose is public before your first customer signs up.

Minutes 1 to 10: the crawl

Internet-wide scanners hit every reachable address on a rolling basis. Honeypot research has shown for years that a freshly exposed host receives its first automated probes within minutes. None of them are aimed at you. They ask the same questions of everyone:

• Which ports answer? Is there something on 22, 3306, 5432, 6379, 9200 that should never have faced the internet?
• What does the web server say about itself? Version headers, framework fingerprints, error pages that name the stack.
• Do the usual paths exist? /.env, /.git/config, /admin, /phpmyadmin, /api/docs, /swagger.json, /graphql, a hundred others. Each request costs nothing, so they try all of them.

This is where most early findings come from, and it is worth being honest about how unglamorous they are. Not zero-days. An .env file served as text. A .git directory left in the build. A database port open with a default password. The scanners are not clever; they are patient.

Minutes 10 to 30: your API, read like a book

Modern front-ends ship with their API baked in. Open the browser's developer tools on your own site and you will see exactly what an outsider sees: every endpoint the page calls, the shape of every request, sometimes the endpoints the page does not call yet but the bundle already knows about. Automated tools do the same thing and then try each endpoint without the checks the front-end would have applied.

1. Can I call it without logging in? Endpoints that the UI only shows to logged-in users, but the server never checks.
2. Can I call it as someone else? Change the ID in /api/invoices/1042 to 1041. If the server does not verify ownership, that is another customer's invoice. This one, broken object level authorization, is the most common serious finding in small SaaS products for a reason: it is invisible from the UI and trivial from the outside.
3. What happens if I send something the UI would never send? Negative quantities, very long strings, a role field on the sign-up request.

Minutes 30 to 60: the things you forgot you had

By now the crawl has moved past the main app to everything around it, and this is usually where the real gaps are. Not in the product you are proud of, but in the scaffolding.

• The staging environment with last month's code and no rate limiting.
• The cloud storage bucket that was public for one demo and never closed.
• The dependency with a published vulnerability, listed in your lockfile for anyone who can read the bundle.
• The API key in a public repository, pushed on a Friday, found by a bot on Saturday. Secret scanners run on every public commit; a leaked cloud key is typically used within minutes of being pushed.
• The subdomain that used to point at a service you cancelled, and now points at nothing, which means it can point at whatever someone else registers there.

None of this required skill, targeting or intent. It required a domain, a certificate and an hour.

What to do about it

The uncomfortable conclusion is that the first hour of your launch is also the first hour of your exposure, and that nobody on your side is usually watching it. The fix is not to launch more carefully. It is to look at your product the way the scanners do, before and after every change, and to fix what that look finds.

1. Know your list. Every domain and subdomain you have ever pointed anywhere. Certificate transparency logs are public; search your own domain in one and see what comes back.
2. Check the boring paths yourself. /.env, /.git/config, your API docs. Five minutes, and the most common serious findings are on that list.
3. Open your own API in the developer tools and try one request as a different user ID. If it works, you have a week of work ahead and you are lucky to have found it first.
4. Make the look continuous. A check you ran once at launch is worth exactly one launch. Wire it to your deploys.

Orja does this first hour for you, from the outside, on demand and then on every merge, and hands back what it found with the fix. If you launched something recently, put in your domain and see what the first hour looked like for you. The first report is free.