Skip to content
Documentation

Verification

Verify a target

Every full scan needs proof you control the target. Four methods are accepted - pick the one that matches your environment.

After you add a target, the dashboard generates a unique verification token (looks like nanotesting-verification=abcd1234ef56...). Place it via one of the four methods below and click Verify on the target page. We poll the target once a minute; verification usually completes in under 60 seconds.

Method 1: DNS TXT record (recommended)

Add a TXT record on the apex. This is the most reliable method for production hosts because it does not require deploying any code change.

name:  @                  (apex, or _nanotesting if your DNS provider requires a sub-record)
type:  TXT
ttl:   60-300 seconds
value: nanotesting-verification=abcd1234ef56...

Cloudflare users: connect Cloudflare in Settings > Integrations with a scoped API token and we can write the record for you with one click.

Method 2: HTML file

Place a plain-text file in the public root of the site:

URL:      https://your-target.example.com/.well-known/nanotesting-verification.txt
content:  nanotesting-verification=abcd1234ef56...

The file must respond with HTTP 200 and a Content-Type of text/plain (or octet-stream). HTML responses with the token embedded do not pass the verifier; the body has to be the token verbatim.

Method 3: HTML meta tag

Add a meta tag in the <head> of the landing page (the one served at /):

<meta
  name="nanotesting-verification"
  content="abcd1234ef56..."
/>

Useful when you can deploy a template change but can't edit DNS or upload a static file. Common case: marketing landing pages on Webflow, Wix, Squarespace, Framer.

Method 4: Domain email

We send a one-time confirmation email to one of:

  • webmaster@your-target.example.com
  • security@your-target.example.com
  • admin@your-target.example.com

Click the link in that email to verify. Useful for SaaS we don't already own DNS for but where the operations team has a mailbox.

Re-verification

Verification tokens are stable across scans; you do NOT need to re-verify between scans. We DO re-resolve the target's hostname on every scan dial to defeat DNS rebinding attacks - if the hostname starts resolving to a private IP between scans, the worker refuses to connect and the scan errors out rather than scanning your worker's network neighbours.

What can't be verified

Some hosts cannot be verified through any of the four methods and therefore cannot be scanned through NANOTESTING:

  • Private IPs, localhost, and link-local addresses
  • Cloud-metadata endpoints (169.254.169.254, fd00:ec2::254)
  • Targets behind a VPN or zero-trust network that we cannot reach from the worker
  • Bug-bounty programs where the program owner has not given you written permission (see the Acceptable Use Policy)

For internal scans, the Enterprise plan can ship an internal scanner agent. Contact support@nanotesting.com.