Domain Verification for Responsible Vulnerability Scanning
Vulnerability scanning is a powerful tool for improving security, but with that power comes responsibility. Scanning a target without authorisation is at best unethical and at worst illegal. Domain verification is the mechanism that ensures scans only run against authorised targets. This guide covers why verification matters, how the major verification methods work, and the broader set of safeguards that responsible scanning platforms implement to protect both operators and targets.
Why Verification Is Necessary
Vulnerability scanning sends probing requests to a target system. While external scanning is non-destructive by design, it still generates traffic that can appear suspicious in security logs, trigger intrusion detection systems, and cause concern for the target's security team. Without verification of authorisation, there is no way to distinguish a legitimate security assessment from a malicious reconnaissance operation.
The legal implications are significant. In most jurisdictions, scanning a system without authorisation can violate computer misuse laws. The UK's Computer Misuse Act 1990, the US Computer Fraud and Abuse Act (CFAA), and similar legislation in other countries criminalise unauthorised access to computer systems. While legitimate security scanning is not typically prosecuted, the distinction between authorised and unauthorised scanning is precisely what domain verification establishes.
Beyond legal considerations, verification is an ethical requirement. The security community operates on trust. Responsible disclosure, coordinated vulnerability reporting, and ethical hacking all depend on clear boundaries between authorised testing and unauthorised intrusion. Domain verification provides a verifiable, auditable record that scanning was conducted with proper authorisation.
Verification Methods Explained
Three primary verification methods are used by scanning platforms. Each proves a different type of control over the target domain, and each has different trade-offs in terms of convenience and the level of access required.
The most common and most trusted method. The scanning platform generates a unique verification token and asks you to add it as a TXT record on your domain's DNS zone. For example, you might add a record likesecportal-verify=abc123xyzto your domain. The platform then performs a DNS lookup to confirm the record exists.
DNS verification proves you have administrative access to the domain's DNS configuration, which is typically restricted to domain owners or their authorised administrators. It works for any domain regardless of whether a web server is running, making it suitable for verifying domains that host APIs, mail servers, or other non-web services.
This method requires adding a specific meta tag to the HTML of the domain's root page. The scanning platform provides a tag like<meta name="secportal-verify" content="abc123xyz" />which you place in the <head> section of your homepage. The platform then fetches the page and checks for the tag.
Meta tag verification proves you have the ability to modify the content of the web server, which implies either ownership or administrative access to the application. It is easier than DNS verification for teams that have web server access but not DNS access, which is common in large organisations where DNS is managed by a separate infrastructure team.
The platform generates a verification file with a specific name and content, and asks you to upload it to a known path on your web server, typically the root directory. For example, you might place a file at/.well-known/secportal-verify.txtcontaining the verification token. The platform fetches this URL to confirm the file exists with the correct content.
File upload verification is similar to meta tag verification in what it proves (web server access) but can be easier for static sites or applications where modifying HTML templates is more complex than adding a file. It follows the well-known URI pattern used by other verification systems like Let's Encrypt and security.txt.
Verification Lifecycle
Domain verification is not a one-time event. As your attack surface evolves, ownership and authorisation can change over time: domains are sold, hosting providers change, team members leave organisations, and consulting engagements end. A verification that was valid six months ago may no longer reflect current authorisation.
Responsible platforms enforce verification expiry periods, typically 90 days. After expiry, the domain must be re-verified before scanning can continue. This ensures that ongoing scanning is backed by current authorisation rather than a stale approval from months earlier. The re-verification process is usually seamless if the verification record (DNS TXT, meta tag, or file) is still in place.
For security consultancies managing client engagements, the verification lifecycle should align with the engagement period. Verify the client's domain at the start of the engagement and allow verification to expire naturally when the engagement ends. If the engagement is extended, re-verify. This creates a clean audit trail of scanning authorisation that aligns with your commercial agreements.
Attestation for Third-Party Domains
Security consultants often need to scan domains they do not own. A penetration tester assessing a client's web application cannot add DNS records to the client's domain. In these cases, an attestation or letter of authorisation serves as the verification mechanism.
An attestation is a formal declaration that the domain owner authorises a specific party to perform security scanning against their domain for a defined period. It should include the domain(s) to be scanned, the authorised party (organisation and individuals), the authorised scan types, the authorisation period, and the signature of an authorised representative of the domain owner.
Attestation verification is typically a manual process where the scanning platform reviews the submitted documentation before enabling scanning for the specified domain. While slower than automated DNS or meta tag verification, it provides the flexibility needed for consulting engagements while maintaining the accountability that responsible scanning requires.
Beyond Verification: Comprehensive Scan Safety
Domain verification ensures you are scanning the right target. But responsible scanning platforms implement additional safeguards to ensure that scanning is conducted safely, even against authorised targets.
Certain targets should never be scanned, regardless of claimed authorisation. This includes critical infrastructure domains (government, healthcare, emergency services), domains belonging to cloud provider control planes (AWS console, Azure portal, GCP console), and internal/reserved IP ranges. Responsible platforms maintain blocklists that prevent scans against these targets even if someone attempts to verify them.
Even authorised scanning should not overwhelm the target. Rate limiting ensures that scan traffic stays within reasonable bounds and does not cause denial-of-service conditions. Scanning platforms should implement per-target rate limits, global rate limits, and concurrent scan limits to prevent any single scan from generating excessive load.
Server-Side Request Forgery (SSRF) protection prevents scanning infrastructure from being used to scan internal resources. If a user provides a target that resolves to a private IP address (10.x.x.x, 172.16-31.x.x, 192.168.x.x) or localhost, the scan should be blocked. This prevents the scanning platform from being abused as a proxy to attack internal networks.
External vulnerability scans should be read-only by design. They should not attempt to exploit vulnerabilities, modify data, create accounts, or perform any action that changes the state of the target. The goal is to identify vulnerabilities, not to demonstrate exploitation. This principle ensures that scanning cannot cause unintended damage even if it runs more aggressively than expected.
Every scan should be logged with the verified target, the user who initiated it, the scan type and configuration, timestamps, and results. This audit trail provides accountability and can be used to investigate any concerns raised by target owners about scanning activity.
Best Practices for Responsible Scanning
- Always verify domain ownership before scanning, even for targets you are confident you own
- Keep verification records in place for the duration of your monitoring programme to ensure uninterrupted scheduled scanning
- For consulting engagements, obtain written authorisation before scanning and keep it on file
- Inform the target organisation's security team before scanning so they are not alarmed by the traffic
- Schedule scans during business hours if possible so that any issues can be quickly investigated and addressed
- Review scan results promptly and report critical findings to the target owner immediately rather than waiting for a formal report
- Use scanning platforms that implement the safety controls described above: blocklists, rate limiting, SSRF protection, and audit logging
- Remove verification records when authorisation ends to prevent stale scanning permissions
- Document your scanning programme's responsible use policy and share it with clients and stakeholders
How SecPortal Implements Responsible Scanning
SecPortal implements all of the safety mechanisms described in this guide. Domain verification is mandatory before any scan can execute, supporting DNS TXT, meta tag, and file upload methods with 90-day expiry and re-verification. Attestation-based verification is available for consulting engagements where DNS access is not available.
The platform maintains a comprehensive blocklist of domains that cannot be scanned, including critical infrastructure, cloud provider control planes, and government domains. All scan targets are validated against this blocklist before execution. SSRF protection prevents scans against private IP ranges and localhost. Rate limiting is enforced per-target and globally to prevent excessive load.
All scanning is non-destructive by design. The scanner sends standard HTTP requests, DNS queries, and TCP connection attempts but never attempts to exploit vulnerabilities or modify target state. Full audit logs are maintained for every scan, providing a complete record of what was scanned, when, by whom, and what was found. This approach ensures that running a vulnerability scan through SecPortal is safe, legal, and responsible by default.
Responsible scanning by default
SecPortal enforces domain verification, maintains blocklists, implements SSRF protection, and logs every scan. Scan responsibly from day one. No credit card required.
Get Started Free