Security
Network tools can be misused to probe internal systems. We take deliberate steps to prevent that while keeping the legitimate tools useful.
SSRF protection
Every server-side feature that fetches a user-supplied URL or hostname goes through a shared protection module that:
- allows only
httpandhttpson a small set of safe ports; - rejects credentials embedded in URLs;
- resolves the hostname and blocks any private, loopback, link-local, reserved, or cloud-metadata address;
- re-validates the target after DNS resolution (to defend against DNS rebinding) and on every redirect hop;
- enforces timeouts, a redirect limit, and a maximum response size, and never downloads full response bodies.
Private network blocking
Requests to localhost, RFC 1918 ranges, 169.254.0.0/16, unique-local IPv6, and metadata endpoints such as 169.254.169.254 are refused. Private and reserved IPs entered into lookup tools are classified locally and not sent to external services.
Input validation & rate limiting
All API inputs are validated (size, format, and type). Endpoints apply rate limiting to reduce abuse, and we minimize what we log.
Secrets
API keys, when used, are stored as server-side secrets and are never included in the client bundle.
Features we deliberately don’t build
- Full or ranged port scanners, CIDR/mass-host scanners, and private-network scanners.
- Vulnerability or banner-grabbing scanners.
- Anything designed to bypass authentication or evade detection.
Optional tools like a single-port checker are gated behind feature flags and ship only with abuse safeguards in place.
Reporting a vulnerability
If you believe you’ve found a security issue, please email support@example.com with details and steps to reproduce. Please do not publicly disclose until we’ve had a reasonable chance to respond.
Acceptable use
Use these tools only against systems you own or are authorized to test. Do not use them to probe or attack third-party infrastructure.