AbuseRoute: Security & Data Handling Summary

Version 1.0. Last reviewed: 17 September 2026

This page answers the questions security teams usually ask before adopting an external API. It describes the service as it is today, operated by a single provider. Where a control is planned rather than in place, it says so.

What the service is

A read-only HTTP API. Input: a domain name. Output: public registration, DNS and abuse-contact information for that domain, plus an infrastructure classification. No customer data is uploaded beyond the domain name being queried. No account portal, no stored user content.

Architecture

• Single Rust service behind nginx, fronted by Cloudflare (TLS termination at edge; TLS to origin).
• Hosted on AWS EC2, London region (eu-west-2). Service bound to localhost only; nginx is the sole ingress; SSH restricted to the operator's key.
• Systemd hardening: dedicated unprivileged user, read-only filesystem except a state directory, no new privileges, private /tmp, kernel/cgroup protections, IPv4/IPv6 only.
• No database. State consists of an API-key configuration file (root-readable only) and three small JSON files owned by the service user (mode 0600): issued API keys, usage metering, and key requests submitted through the website form.
• Outbound: DNS resolution, and HTTPS to IANA, RIR RDAP servers, and registry/registrar RDAP or port-43 WHOIS servers. Requests to registries are serialised per host with a fixed identifying User-Agent.

Data handling

• Customer inputs (domain names): logged with key identifier, timestamp, requesting IP and outcome for security and metering. Held in the service journal on a rotating basis and kept no longer than 90 days; explicit 90-day enforcement is configured on the dedicated production instance (see roadmap). Not analysed beyond quota/abuse detection.
• Lookup results: returned to the requester; held only in an in-memory cache (network data up to 24 h, registration data up to 1 h) to avoid repeat upstream queries. Never written to disk, never indexed.
• API keys: stored in full in a root-only file and a service-user-only usage file; displayed masked everywhere else; transmitted only over TLS.
• Personal data: see the Privacy Policy. In short: business contact details of customer staff; request metadata; transient public registration contacts.
• Data location: UK (AWS London). Cloudflare edge may process request headers globally.

Access control

• Per-customer API keys with per-minute rate limits and daily/monthly quotas. Trial keys expire automatically.
• Operator dashboard (usage view, key issue and revocation) is reachable only from the server itself over SSH; blocked at nginx and by the application for any proxied or cross-origin request. Keys are revoked or issued without a service restart.
• Administrative access: one operator, SSH key authentication only, no password login.

Availability

• Trial, Starter and Pro plans: reasonable efforts, no SLA. Planned for the Business tier: dedicated instance, uptime monitoring with alerting, and a published SLA.
• Upstream dependencies (registries) are outside our control; the service degrades gracefully (a lookup returns partial data with the missing section null rather than failing outright).
• Backups: configuration and state are small and reproducible from the deployment repository; the metering file is the only stateful artefact and its loss affects trial-clock and quota counters only.

Change and vulnerability management

• Code in a private git repository; each production deploy corresponds to a tagged commit (current: v0.3.3). Rust toolchain; dependencies from crates.io, updated deliberately rather than automatically.
• No third-party JavaScript, no tracking, no CMS. Attack surface is the API itself and nginx.
• Vulnerability reports: contact@abuseroute.com. We acknowledge within 2 business days. We do not currently run a paid bounty.

Incident response

• Single operator; monitoring via service journal and Cloudflare analytics. Planned: automated uptime and error-rate alerting.
• If a key is compromised: revoke and reissue on request, same day. If customer data (request metadata) is exposed: affected customers notified within 72 hours with what, when and remediation.

Compliance position

• UK sole trader; UK GDPR applies. Data processing addendum available for EU customers on request.
• Upstream data sources are used under their published terms. RIPE NCC and APNIC have each confirmed in writing (September 2026, tickets on file) that our per-address abuse-contact lookups require no permission or registration: RIPE NCC's position is that use compliant with the RIPE Database Acceptable Use Policy is not interfered with, and we query in the non-recursive form they advised; APNIC confirmed lookups may continue as today. Written authorisation requests to ARIN and AFRINIC and a courtesy notice to LACNIC are outstanding. Customer terms carry purpose limitations at least as strict as those sources require.
• No formal certification (ISO 27001, SOC 2); not planned before a dedicated production environment exists.

Roadmap items that change this page

• Dedicated production instance and monitoring (on first paid contract).
• Cloudflare Origin CA certificate and Full (strict) TLS mode.
• Log retention automation (journald 90 days) and metering-file pruning.

---

Contact. Khaled Doulami, trading as WappDev. contact@abuseroute.com. https://wappdev.co.uk