Outside Reading Policy & Responsible Disclosure

1. Outside-in reviews we start ourselves#

When we review a firm that has not asked us to, we look only at what the firm already shows the public. We use:

• Public records: DNS and mail records (MX, SPF, DKIM, DMARC), the site’s security certificate, public certificate logs, public registration (WHOIS) data, published breach databases, and public internet indexes that already list which services a server answers on.
• Ordinary page visits: the homepage, a few pages it links to (such as the contact and about pages), the scripts it loads and the source-map file that usually sits beside each script, the same content any browser receives, and the response headers that come with them. We also read the standard files a site publishes for machines (robots.txt, the sitemap and the mail-security policy file) and the front page of the firm’s public subdomains.

On a review we start ourselves we do not:

• open a connection to any of the firm’s service ports;
• request hidden paths or files, such as /.env, /.git/config or key files;
• check storage bucket names, list WordPress authors or check client-portal addresses.

Those checks run only on an authorised assessment, under section 3. Where a public internet index already lists a service on one of the firm’s servers, we report what the index says; we do not connect to the service to confirm it.

What we share: the result goes only to the firm itself, usually as a private briefing link sent to the firm. We do not publish it and we do not give it to anyone else.

2. Passive reviews for an organisation a firm belongs to or works with#

An association, network, adviser or other organisation may ask us for a summary across the firms it works with. Until a firm agrees on its own page (section 3), we use public records and ordinary page visits only. We make no connection checks, request no hidden paths or files, and run none of the name checks in section 3.

What we share: the summary goes privately to the organisation that asked for it. It is never published.

3. Authorised assessments#

A client who buys an assessment or ongoing monitoring signs an agreement that authorises it. A firm can also agree, on its own consent page, to a full check asked for by an organisation it works with. Within that agreement we run the checks in section 1 against the domains named, and repeat them on the schedule the agreement sets. We also run the checks that a review we start ourselves leaves out:

• Connection checks: whether 15 commonly exposed service ports (for example remote desktop, database and file transfer ports) accept a connection, on every IPv4 address of the domain and of its www host, plus two control ports that show whether a server answers on every port. We open the connection, read any greeting the service sends on its own, and close it. We do not log in, send credentials or try passwords.
• Hidden paths: one request to each of a short list of well-known paths, such as /.env, /.git/config or key files, to see whether the file is served to the public.
• Name checks: whether a public storage bucket exists under names that match the firm, whether a WordPress site lists its authors publicly (we stop at three names), and whether common client-portal addresses answer.

Where a sensitive file is served to the public, a paying client’s own evidence includes a short, redacted extract, so the client can see what was exposed. Any passwords, keys or tokens in that extract are removed before it is stored.

What we share: the results of a paid assessment belong to the client and go only to the client. The results of a check a firm agreed to go to the organisation that asked for it, and alerts about changes go to the firm itself, as its consent page says.

4. Checks a policyholder has agreed to#

An insurer may ask its policyholders whether they agree to a check. Nothing is checked until the policyholder agrees on its own page. The check is passive, as in section 2, and is repeated monthly while agreement stands. The policyholder can refuse, or withdraw at any time on the same link; withdrawal stops the checks and removes the results the insurer can see. We never contact a policyholder ourselves.

What we share: the results go to the insurer while the policyholder’s agreement stands.

What we never do, in any of the four#

How to identify our requests#

Every request a review sends to a firm’s own website names LeakTrace in its User-Agent. Most carry this one:

LeakTrace-Scanner/1.0 (security audit; contact: [email protected])

A few checks send LeakTrace-EASM/2.0 or LeakTrace-Categorizer/1.0 instead. None of our review requests pretends to be an ordinary browser.

How to opt out#

To ask us to stop reviewing your domain, email [email protected] from an address at that domain, or from any address that can show authority over it. We will:

• Add the domain and its subdomains to our do-not-review list within 24 hours. Our systems check that list before every review and refuse any domain on it, with no person needed to remember it.
• Stop every future review of it, of any of the four kinds above, unless the domain’s owner later signs for an assessment.
• Confirm by email when this is done.

A policyholder can also refuse or withdraw on its own consent page at any time, with no email needed.

Coordinated disclosure: exposure found in a third party#

Occasionally during a customer assessment, LeakTrace will discover an exposure that does not belong to the customer. For example, a publicly-exposed credential in a third-party vendor used by the customer, or a misconfiguration on a partner organization's domain. Our handling of these findings:

• The finding is reported confidentially to the LeakTrace customer who commissioned the assessment, the same as any other finding in their report.
• LeakTrace will not directly contact the affected third party without the customer's permission, and will not publicly disclose the finding.
• Where the customer wishes to notify the third party, LeakTrace can provide a redacted technical description suitable for forwarding, on request.
• Where the exposure represents an active, ongoing risk to the public (for example, an actively-leaking public bucket holding consumer data of a non-customer), LeakTrace reserves the right, after a 30-day customer-notification window, to disclose responsibly to the affected third party under our standard [email protected] coordinated-disclosure process, regardless of the customer's preference. We will inform the customer in writing before doing so.
• We never disclose to law enforcement, regulators, journalists, or competitors of the affected third party without an explicit legal obligation to do so.

If you are a third-party organization who believes LeakTrace has information about an exposure affecting you, email [email protected]. We will respond within 72 hours and, where appropriate, share what we can without breaching customer confidentiality.

Reporting a vulnerability in LeakTrace#

If you have discovered a security vulnerability in any LeakTrace property (getleaktrace.com or any subdomain or product surface), please report it to [email protected]. We commit to:

• Acknowledge your report within 72 hours
• Provide a status update within 7 days
• Resolve confirmed critical issues within 30 days
• Credit you publicly (if you wish) on the Acknowledgments section below

We do not currently operate a paid bug-bounty program. We deeply appreciate responsibly-disclosed reports.

Legal basis#

Our reviews rely on information that the organisation already serves to the public, and on the written agreement or recorded consent where section 3 or 4 applies. We do not seek access beyond what is served publicly, and we do not use anything we find to gain further access. If you have a question about a specific review, contact us and we will provide the dates, the requests we made and our method.

Acknowledgments#

We thank all security researchers who have responsibly disclosed issues to us. (No public acknowledgments at this time.)

Change log#

• 30 September 2026: a review we start ourselves no longer requests hidden paths or files such as /.env or /.git/config; that check now runs only on an authorised assessment. Section 1 no longer lists connection checks, which have not run on reviews we start ourselves since 29 September 2026. Section 3 now lists every check an authorised assessment adds. The User-Agent section names every identifier our reviews use.
• 30 September 2026, earlier: product name updated to External Cybersecurity Assessment. Scope and limits unchanged.
• 29 September 2026: security reports go to [email protected].