Skip to main content

Security Overview

How WorldIP.io protects the service, your account, and your data. Last updated: October 5, 2026

WorldIP.io is a production-grade, globally distributed platform that sustains over a billion updates a day across the entire IPv4 address space and answers lookups in under a second. Security is a first-class part of how it is built and run. This page describes, honestly and specifically, the controls we have in place today. We describe the posture we actually operate — we do not claim certifications or audits we have not completed.

HTTPS / TLS everywhere
Every connection is served over HTTPS (TLS 1.2+), terminated behind Cloudflare.
No payment-card data
We do not process or store card details. Billing, when it launches, is handled by a PCI-DSS processor.
Hashed API keys
Our key database stores only SHA-256 hashes of keys. Send keys in the Authorization header — a key put in a ?key= URL is recorded in web-server logs.
Password-free sign-in
A one-time code or link sent to your email, or Sign in with Google. We never store a password.
Least-privilege access
Operator access is key-based and limited to a private management network.
Public network data only
We index public allocation, DNS and routing data. We do not port-scan or probe services.

Transport & network security

All traffic to WorldIP.io is served over HTTPS with TLS 1.2 or higher. The site sits behind Cloudflare, which provides edge TLS termination, a global CDN, and DDoS protection. Plain-HTTP requests are redirected to HTTPS.

Session and authentication cookies are issued with the Secure, HttpOnly, and SameSite=Lax flags, so they are only ever transmitted over HTTPS, are not readable from JavaScript, and are not sent with cross-site form posts or embedded requests — closing off the common session-theft and CSRF cookie vectors.

No payment-card handling

WorldIP.io does not currently take payments, and at no point do we store, transmit, or have access to your payment-card details. When paid API plans launch, card processing will be delegated entirely to a PCI-DSS-compliant payment processor (PayPal); card numbers are entered directly with the processor and never touch our servers. This removes an entire class of sensitive data — cardholder data — from our systems by design.

Account authentication

Accounts use passwordless sign-in: we email you a one-time 6-digit code and link (single use, valid for 15 minutes, stored only as a salted hash), or you can use Sign in with Google (OAuth 2.0), where we never see your Google password and request only your basic profile and email. There is no password to steal, reuse or reset, and no password database to breach.

Login state is carried in a stateless, HMAC-signed cookie (wio_auth) rather than a server-side session store: each server independently verifies the signature against a shared secret, so a tampered or forged cookie is rejected. Anonymous requests carry no such cookie, which also keeps public pages cacheable at the edge. You can permanently delete your account and all associated data yourself, instantly, from your account page.

API key security

Our API is authenticated with least-privilege keys, designed so that a leaked key does the least possible damage:

  • Hashed at rest — our key database stores only a SHA-256 hash of each key, so a lost key cannot be recovered from it. Incoming keys are matched by hash. A key sent in the deprecated ?key= query parameter is part of the request URL and is therefore recorded in our web-server logs; send it in the header instead (below).
  • Scoped — every key is limited to the specific capabilities it needs; a request outside the key’s scope is rejected.
  • Rate-limited — each key has its own sliding-window rate limit, enforced independently of other keys and of anonymous traffic.
  • Origin- and IP-lockable — a key can be bound to a specific site origin (enforced on browser calls) and/or to an allow-list of caller IP addresses (the strongest lock for server-to-server use).
  • Revocable — a key can be disabled instantly and replaced with a new one.

Send your key in an Authorization: Bearer <key> header. The ?key= query parameter is deprecated: it is still accepted, but a key in a URL is written to web-server logs and can leak through referrers and browser history.

Application & anti-abuse hardening

  • CSRF protection — state-changing actions (contact form, account changes, key regeneration, deletion) require a CSRF token verified with constant-time comparison, and same-origin checks reject cross-site submissions.
  • Adaptive rate-limiting — sliding-window per-IP and per-key limits protect every website and API endpoint from scraping and brute force, backed by an automated anti-abuse firewall that throttles or blocks abusive request patterns.
  • Input validation — IP, CIDR, ASN and domain inputs are strictly validated before use, and database access uses parameterized queries throughout.
  • Layered form defences — the contact form combines a hidden honeypot, a minimum dwell time, a JavaScript challenge, referrer verification, and content heuristics; the sign-in form sits behind a Cloudflare bot check and adds a honeypot, CSRF and same-origin checks, and per-client and site-wide abuse limits. Both stop automated spam without tracking you.
  • Separated administration — the public site carries no admin surface; operations run on a separate control panel reachable only from our private network, so admin functionality is not exposed to the internet.

Infrastructure posture

WorldIP.io runs on infrastructure we operate across North America, Europe and Asia-Pacific, interconnected over an encrypted WireGuard mesh. Inter-service traffic travels over this private network rather than the public internet, and management interfaces are not exposed publicly.

Operator access is key-based and least-privilege: administrative access uses SSH keys (no shared passwords) and is restricted to authorized operators reaching hosts through the private mesh. Public-facing components are firewalled to accept only the traffic they need.

Authoritative data sources & integrity

Our data is compiled only from authoritative, public sources, and we publish where each field comes from so results are auditable:

  • MaxMind GeoLite2 — IP-to-country/-city/-ASN mappings.
  • IANA + RIR delegation files — ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC allocation and transfer records.
  • ipinfo Lite — supplementary ASN/country coverage.
  • Public DNS (PTR) — reverse hostnames and their forward confirmation (FCrDNS), resolved by our own scanners.
  • issued.live (sister service, Tuxxin LLC) — a weekly count of the domains hosted on each address, computed by WorldIP from issued.live's DNS snapshot.
  • GRIP (General Research IP) — residential and mobile proxy observations, and the forward-DNS data of the keyed lookup API.
  • RIPE RIS routing + RPKI — live BGP announcements, origin ASNs and route validity.
  • Public RDAP / WHOIS and curated threat-intelligence blocklists — ownership detail and reputation signals.

We only resolve public DNS and routing data. We do not port-scan, probe services, or make application-level connections to the addresses we index. Full licensing and attribution is documented on our data sources & methodology page.

Privacy by design

The data we publish describes networks, not identified people. The personal data we do hold is minimized: web lookups need no account; lookup rate limits store only a one-way hash of your IP (the sign-in form keeps the IP address, or IPv6 /64 network, for 2 days to stop abuse); API keys are stored as hashes (a key sent in a deprecated ?key= URL also appears in our web-server logs); and we do not sell personal information. See our Privacy Policy for the full detail on what we collect and your rights.

Certifications & honest posture

We believe in being straight with you about what we have and haven’t done. WorldIP.io follows the security practices described on this page, but we do not currently hold formal third-party certifications such as SOC 2 or ISO 27001, and we have not undergone an external security audit. We would rather state that plainly than imply assurances we cannot back up. As the service and its paid tiers mature, we intend to formalize and expand these controls, and we will update this page when we do.

Responsible disclosure

If you believe you have found a security vulnerability in WorldIP.io, we want to hear from you. Use our contact form with enough detail to reproduce the issue. We will acknowledge your report, investigate, and keep you updated on remediation.

Good-faith safe harbor. If you make a genuine, good-faith effort to comply with this policy during your research, we will not pursue or support legal action against you, and we will work with you to understand and resolve the issue quickly. We simply ask that you:

  • give us a reasonable opportunity to fix the issue before disclosing it publicly;
  • avoid privacy violations, data destruction, service degradation, and access to or modification of data that is not yours;
  • use only your own accounts and test data, and stop at the point of demonstrating the vulnerability rather than exploiting it further;
  • do not run automated high-volume scans, denial-of-service tests, or social-engineering / physical attacks against our staff or infrastructure.

We do not currently run a paid bug-bounty program, but we are grateful for responsible reports and will happily credit researchers who would like to be acknowledged.

Reporting scanning or abuse

WorldIP.io operates a reverse-DNS (PTR) scanner that resolves public DNS records. If you have questions about traffic you have seen from our scanner, or want your network excluded, use our contact form or read our scanner information page, which explains exactly what we do and don’t do.

Contact

Security vulnerabilities: contact form

Scanning / abuse questions: contact form

Everything else: our contact form.

Share