Security at TrustSek

How our scans behave

TrustSek scans are non-intrusive. A scan scores a domain from the outside, and most of what it uses is already public. When it does touch a domain's own servers, it does what a browser or a mail server would do, and nothing more.

DNS

MX SPF DMARC DKIM MTA-STS TLS-RPT CAA NS DNSSEC

TLS

:443 · one handshake

HTTPS

GET / · one request

HTTP

GET / :80 · one request

MTA-STS

policy file, if published

UA

TrustSek/1.0

No port scans · no exploits · no crawling · no logins

What we send to the domain being scanned

• DNS lookups. We read the domain's public DNS records: mail, SPF, DMARC, DKIM, MTA-STS, TLS-RPT, CAA, nameservers and DNSSEC. For DKIM we look up a list of common selector names. Subdomains found in certificate transparency logs are resolved in DNS to see which are live.
• One TLS connection to port 443, to read the certificate, the protocol version and the cipher your server chooses.
• Two web requests for the home page: one over HTTPS and one over HTTP on port 80, to see whether plain HTTP redirects to HTTPS. We read the response headers and the page's HTML to identify advertised software versions.
• Your MTA-STS policy file, if your DNS says you publish one.

Web requests identify themselves with the user agent TrustSek/1.0. Requests to the same target are spaced out rather than sent in a burst, and every request has a short timeout.

What we do not do

• We do not scan ports. Open ports and exposed services come from an internet-scanning data provider that has already observed them, not from us.
• We do not send exploit payloads, fuzz inputs, try passwords or test for vulnerabilities. Vulnerability findings are matches between advertised software versions and published advisories.
• We do not crawl the site, follow links, submit forms or log in.
• We do not connect to lookalike domains. We check in DNS whether they are registered, then ask threat-intelligence sources about the ones that are.

The methodology lists every source and what each one reads.

If you saw our requests

If requests from TrustSek/1.0 appeared in your logs, someone ran a scan of your domain, or one of your suppliers or partners did. The requests above are the whole of it. Contact us if you have questions.

How we handle data

• Third-party sources. To check a domain, we send the domain name, and for some sources its resolved IP addresses, to the sources listed in the methodology, such as certificate transparency logs and threat-intelligence services.
• Checked domains. The app stores the domains that are checked, and their results. Do not treat a check as private.
• API keys are stored only as a one-way hash. The full key is shown once, when it is created, and a revoked key stops working on the next request.

Report a vulnerability

If you believe you have found a security vulnerability in TrustSek, please tell us. We would rather hear about it from you than from anyone else.

Email your report to security@trustsek.com. You can write in English or Swedish. We acknowledge every report within 3 working days.

In scope

• This website.
• The TrustSek app at app. on our domain.
• The TrustSek API at api. on our domain.

Out of scope

• Findings that TrustSek reports about other people's domains. If you think a score or finding is wrong, contact us instead.
• Services run by third parties we use, such as our hosting provider or the data sources we query. Report those to the provider.
• Reports from automated scanners with no proof of impact.
• Missing best-practice headers or records with no demonstrated security impact.
• Denial-of-service, spam or social-engineering attacks.

What to include

• What you found and where: the URL, endpoint or component.
• Steps to reproduce it, and what an attacker could achieve.
• Any proof-of-concept, kept to the minimum needed.
• How we can reach you, and whether you want to be credited.

What we ask you not to do

• Do not access, change or delete data that is not yours. Use test accounts you created yourself. If you reach another customer's data by accident, stop, do not keep it, and tell us.
• Do not run denial-of-service tests, high-volume automated scanning or anything that degrades the service for others.
• Do not use social engineering, phishing or physical attacks against our staff or offices.
• Do not publish or share the issue until we have fixed it, or agreed a date with you.

What we promise in return

If you act in good faith and follow this policy:

• We will acknowledge your report within 3 working days and keep you informed while we work on it.
• We will not take legal action against you, or ask anyone else to, for research that stays within this policy.
• We will credit you when the fix is published, if you want us to.

We do not run a bug bounty and do not pay for reports.

security.txt

We publish our security contact in a machine-readable file at /.well-known/security.txt, following RFC 9116. It lists the reporting address, preferred languages (Swedish and English), a link to this page and an expiry date, which we renew every year.

This site

A security company's own site should pass the checks it runs on others. This site is served over HTTPS only, with HSTS and a strict content security policy.