Security

Security & data handling

Last updated: 14 May 2026.

urlcap is operated by DATO CAPITAL LTD (UK company 09987396). This page is the canonical description of how the service handles your data — transport, secrets, captured request bodies, TOTP shared secrets, logs, retention, and how to disclose a vulnerability. For the legal commitments around all of this, see the Privacy Policy and Terms of Service.

Encryption in transit

• All endpoints under https://urlcap.com/ require TLS 1.2+ — cleartext requests are refused at the edge.
• Strict-Transport-Security is set with a long max-age and includeSubDomains.
• Modern cipher suites only; legacy ciphers (RC4, 3DES, CBC-mode in TLS <1.2) are disabled.
• Forward secrecy via ECDHE.

Authentication & API keys

• Passwords are hashed with bcrypt (cost factor 12) — we never store or log a cleartext password.
• API keys are randomly generated, displayed once at creation, and stored as a salted hash; revoke them at any time from API keys.
• Sessions are HTTP-only, Secure cookies with SameSite=Lax; CSRF-protected form posts.
• Social sign-in (Google / GitHub / Microsoft) uses standard OAuth 2.0 / OIDC; we receive your email address and a stable account identifier and nothing else.

Captured request & response data

The /api/v1/capture endpoint dispatches an HTTP request to a target URL on your behalf and returns the response. Treat your captured data like you would treat the contents of your browser's network panel:

• Request specs (URL, headers, body, options) are processed in memory for the duration of the call and are not persisted as a side-effect.
• Response bodies returned to you are not stored server-side — they live only in the JSON response that goes back over the wire.
• If you ran the capture as part of a scheduled task, each run's result is stored under your account so you can fetch it later; you can delete those runs at any time.
• The proxy's outbound socket re-uses urlcap's own pool — your target sees the urlcap IP and a configurable User-Agent, never a residential IP.
• Do not send credentials (cookies, bearer tokens, API keys for other systems) that you wouldn't want to share with a developer-facing API. See logs & analytics for what's recorded.

TOTP secrets

The /api/v1/totp endpoint takes an otpauth:// URI containing the shared secret, computes the current code, and returns it. Because the URI carries cryptographic material, it gets extra handling:

• The URI is processed in memory for one request and is never persisted — no DB write, no disk write, no caching.
• The uri query/body parameter is redacted from request logs before any log line is written and is excluded from analytics.
• The endpoint is intended for testing and internal automation against systems you own (CI smoke tests, machine-to-machine 2FA against an internal service). It is not intended as a remote store for your personal 2FA accounts — for that, use an authenticator app on a device you control.
• If a TOTP URI is ever sent over a 4xx/5xx error path (e.g. you mis-form the request), the request body is dropped from the error log and replaced with a structural placeholder.

Logs & analytics

• Each API call records a row in usage_events with: endpoint, HTTP method, response status code, request units, IP address, User-Agent, latency, and timestamp.
• Sensitive request fields are redacted or replaced with placeholders before reaching usage_events — notably the TOTP uri and any Authorization / X-API-Key headers.
• Full-detail rows are kept up to 90 days; aggregated counters (per-day, per-endpoint) are retained indefinitely for billing and capacity planning.
• We do not run third-party tracking or advertising analytics on the site.

Datasets & scheduled tasks

• Datasets and scheduled-task definitions are owned by a single user account and are not shared with other users.
• Dataset items can be IPs/CIDRs or URLs; with history=true each change is preserved so you can audit who/what/when. History is private to the dataset owner.
• Deleted datasets and runs are gone from the live tables immediately; backups age out within 30 days.

Infrastructure & access

• The service runs on a hardened Linux host inside the EU; OS patches are tracked on a regular cadence.
• Database access is least-privilege: the app role can read/write only the application schema; there is no shared "root" account in normal operations.
• Backups are encrypted at rest.
• No customer data leaves the production region by default. Stripe Payments Europe Ltd. processes card data on its own infrastructure; we never see card numbers.

Payments (Stripe)

• Card processing is handled entirely by Stripe Payments Europe Ltd. — urlcap does not see or store card numbers.
• We retain the Stripe customer ID, subscription ID, plan, status and renewal dates for billing operations.
• Stripe webhooks are verified with the signed-payload secret; replay attempts are rejected via a (provider, provider_event_id) uniqueness constraint.

Reporting a vulnerability

If you believe you've found a security issue, please email info@urlcap.com with a clear reproduction. We acknowledge reports within two business days and aim to ship a fix or a clear mitigation plan within 30 days for high-severity issues.

Please:

• Test only against accounts you own; do not access, modify, or destroy data that isn't yours.
• Avoid denial-of-service, social engineering of urlcap staff, and physical attacks against the hosting facility.
• Give us a reasonable disclosure window before going public.

In return we will not pursue legal action against good-faith researchers who follow these rules. We don't currently run a paid bug-bounty programme; we're happy to credit you publicly if you'd like.

Contact

DATO CAPITAL LTD · 71-75 Shelton Street, Covent Garden, London, England, WC2H 9JQ, United Kingdom · info@urlcap.com.