Security at Nameward

Nameward checks your domains from the outside, so the data we hold is small: your account, the domains and hosts you add, and what our checks found. This page explains how we look after it and how to tell us about a problem.

How we store your data

• Data lives in a Postgres database on an Oracle Cloud Infrastructure server, backed up nightly; backups are kept for 30 days.
• Connections to Nameward use encrypted HTTPS.
• We don't store passwords. You sign in with a link and a 6-digit code sent by email. The link and code are single-use, expire after 15 minutes and are stored only as hashes.
• You can also add a passkey and sign in with your fingerprint, face or device PIN. Your device keeps the private key and checks your fingerprint or face itself; we store only the public key, which can't be used to sign in. Each sign-in answers a fresh, single-use challenge, and a passkey that shows signs of being copied is refused. Email sign-in always stays available.
• Session cookies are random values; we store only their hashes, so a copy of the database can't be used to sign in as you.
• The web app sends strict security headers and protects every form against cross-site requests.

What our scanners touch

Nameward uses public data only:

• public DNS records;
• RDAP and WHOIS registration data;
• Certificate Transparency logs;
• TLS handshakes with the hosts our customers add.

We never ask for credentials and never install agents. The prober refuses to connect to private, internal or loopback addresses and cloud metadata endpoints. It checks the address it is about to connect to, so a DNS record pointing somewhere private can't trick it. Alert webhooks are held to the same rule.

Signed alert webhooks

If you send alerts to your own webhook, each request carries a signature header:

X-Nameward-Signature: t=1761811200,v1=5d41402abc4b2a76b9719d911017c592...

t is the Unix time the request was sent. v1 is the hex-encoded HMAC-SHA256 of the string t.body (the timestamp, a dot, then the raw request body), keyed with your webhook secret.

To verify a request:

1. Read t and v1 from the header.
2. Compute HMAC-SHA256 of t + "." + body with your secret.
3. Compare it with v1 using a constant-time comparison.
4. Reject requests where t is more than a few minutes old.

Webhooks are sent over HTTPS only and don't follow redirects.

Reporting a security issue

If you think you've found a vulnerability in Nameward, email [email protected]. Please include:

• what you found and where (URL, endpoint or feature);
• steps to reproduce it;
• what an attacker could do with it;
• how to reach you.

We'll reply within 3 business days and keep you updated until it's fixed.

We won't take legal action against anyone who researches in good faith and within scope: test only against your own account, don't access other people's data, and give us reasonable time to fix the issue before telling others.

Out of scope:

• denial-of-service or load testing;
• social engineering of our staff or customers;
• spam, or abuse of the sign-in or scan forms to send email or flood them;
• reports from automated scanners with no demonstrated impact.

Our contact details are also published at /.well-known/security.txt.

See also: Privacy · About · Pricing