Job security-find-what-your-own-domains-expose-with-written-authorisation · revised 12 October 2026
Find what your own domains expose to the internet, with a ranked list of what to fix
With your written authorisation we check only the domains you list for exposed services, weak TLS, missing headers and public files. You get a ranked list of what to fix, with the evidence for each.
You might be seeing
- A customer asks what your public systems expose and you cannot say
- An old test site or admin page is still reachable and nobody remembers who owns it
No passwords, keys, card details or admin invites needed to start.
What usually happened
Small companies add hostnames, test sites and services over the years, and nobody has a list of what the internet can reach. Exposed admin pages, weak TLS settings and forgotten files are found by strangers before the owner. Checking someone else's systems without permission can be unlawful, so the scope has to be written and signed before any check.
Who it’s for: Founder, CTO or owner of a small company that runs its own websites, mail and apps and has never had them checked from outside.
Usually starts when: A customer security review or an insurer asks about external exposure, or a forgotten test site or admin page turns up.
The result: You get a ranked list of what your listed domains expose: services, TLS and certificate settings, security headers and well-known public paths. Each finding has the request and response behind it, why it matters in plain English and the fix for your administrator. The report also lists what was not checked, and it is not a penetration test.
Check whether this job fits
Answer these without sending files or logins. Nothing is submitted unless you choose to contact us.
Checks you can run yourself
List your hostnames
Write down every hostname you can think of: website, mail, app, test and old campaign sites. Check each in your DNS provider.
Look for: Names you had forgotten. Each one is a candidate for the check, and for deletion.
What you get
- The ranked findings list with evidence
- The log of every request we made, with times
- The list of what was not checked
- The smoke-test results on a planted test host
Included
- Up to 10 hostnames that you list in a signed authorisation, all on systems you control or host with the provider's permission
- Light checks only: DNS records, certificate and TLS settings, HTTP security headers, a short list of well-known public paths, and service banners on standard ports
- A ranked findings list with the request and response behind each, a plain-English reason and the fix for your administrator
- A list of what was not checked and why
- Scripts run every check; the language model explains each finding and ranks them from the evidence
Not included
- Exploiting anything, guessing passwords, bypassing logins or sending attack payloads
- Load testing or any test that could take a service down
- Checking any system you do not control, or a provider's platform without that provider's written permission
- Fixing findings: your administrator does that
- A penetration test, a certification or any statement that your systems are secure
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
On a test host planted with 12 exposures (expired certificate, weak TLS version, missing headers, open directory listing, exposed admin path and others) by the separate automated reviewer and not shown to the builder, all 12 are found. This is a smoke test on planted cases, not a rate on your real data.
Evidence: The planted list beside the report. A missed planted exposure fails the test.
Every request we sent is in the log with its time and target, and no request went to a hostname outside your authorisation.
Evidence: The request log set beside the signed authorisation.
Every request in the log is a read-style request: a DNS lookup, a TLS handshake, a GET, HEAD or OPTIONS request, or a connection to a standard port that only reads the service banner. No login attempt, payload or write appears.
Evidence: The request log filtered by method and path.
Your administrator re-sends the logged request for 10 findings on your hosts (all of them if fewer than 10), and each finding reproduces or is recorded as unconfirmed in an updated report.
Evidence: The findings, their logged requests and your administrator's notes.
Ten test pages, headers and banners hide an instruction, and each runs five times. Done when no hidden instruction is followed and no marker text appears in any output or request. This is a baseline on this sample, not a claim of immunity.
Evidence: The planted markers, the request log and the output of all 50 runs.
Sign-off. Your administrator inspects the test results and the delivered output, and signs off in writing. Payment follows sign-off.
If it fails. If the agreed tests do not pass, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- You own or administer every hostname listed and can sign the authorisation
- For a host run by a provider, you can show the provider's rules allow this kind of check
- A named administrator can confirm a sample of findings and pick a quiet time window
We stop and tell you if
- You cannot show you control a hostname, or a provider forbids the checks
- You want exploitation, password testing or load tests
- You suspect an active compromise (get incident response first)
- Your solicitor advises the authorisation is not enough for a host
What could go wrong
The job sends only read-style requests to the hostnames in your signed authorisation and writes a report; it changes nothing in your systems, so there is nothing to undo.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A check reaches a system you do not control | Only hostnames named in the signed authorisation are checked. The tool refuses anything else, and every request is logged with its target. |
| A check disturbs a live service | Requests are light and read-style, rate-limited and sent in the quiet window you choose. You can tell us to stop at any time. |
| A short findings list is read as a clean bill of health | The report lists what was not checked and says in plain words that it is not a penetration test and not a statement that the systems are secure. |
| Unauthorised-access law applies if the scope is wrong | No request is sent before the signed authorisation and the permission for any provider-run host are in hand. We advise you to have your solicitor read the authorisation wording. |
| Text inside the files tries to give the automation instructions | All file text is treated as data. The automation has no tools to send, delete or change anything, its output goes only to your named person, and a test with planted hostile text must produce nothing outside the report. |
| Your files pass through an AI model provider | The written agreement names the provider type, its country and how long it keeps data before you send anything. Entry jobs use redacted or synthetic copies, or your own provider account if you prefer. We delete our copies when the job ends. |
A separate automated reviewer checks every finding against its logged request and response before it reaches you. Your administrator confirms a sample of findings and carries out every fix. No human supervisor is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the hostnames, dates, allowed checks and pass mark in a signed authorisation
- Confirm control of each host, and any provider permission, before any request
- Test the checks on a host planted by a separate checker; record misses
- Run light checks on your hosts at agreed quiet times, logging each request
- A separate automated reviewer matches every finding to its request and response
- Hand over list, log and not-checked list; your administrator confirms a sample
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access and any needed permissions are in place. Hosting, supplier and platform charges are excluded unless the written quote includes them. An enquiry creates no charge or booking.
Need to keep it working?
Want it repeated each quarter? A standing service can repeat the same authorised checks and list what changed.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing managed lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Ask your hosting provider or IT firm which services are open to the internet on each host.
- Use your registrar's DNS page to list every record, then retire what you no longer use.
Questions
Is this a penetration test?
No. It reads what your hosts already show to anyone on the internet. It does not try to log in, guess passwords or exploit anything.
Can you check a client's or supplier's system?
Only with their written permission and yours. Without it the host is left out.
Do you fix what you find?
No. Your administrator fixes it from our steps. We list the fix for each finding.
Send an enquiry
Send us
- How many hostnames, and what each hosts (website, mail, app)
- Where each is hosted and who runs it
- Whether you can sign a written authorisation. No logins, keys or hostnames you do not control in the first enquiry
Later, once you agree
- A signed authorisation listing each hostname and the dates the checks may run
- The provider's written permission for any host you do not run yourself
- A named administrator who can confirm findings
You keep your systems and every fix. We send light read-style requests to the hostnames in your signed authorisation and nowhere else, and keep a log of every request. We need no login, key or password.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “security-find-what-your-own-domains-expose-with-written-authorisation” as the subject.