Credentials and access
- Passwords are one-way hashed and are never stored in readable form.
- API keys are shown once, then stored as keyed hashes with only a limited prefix for identification.
- Portal sessions are revocable, protected by secure cookie settings and paired with CSRF controls.
- OAuth access tokens exist only during the provider callback. Haunt stores the provider’s durable subject identifier, not the access token.
- Production access is limited by role and operational need.
Extraction boundaries
- SSRF validation blocks private, loopback, link-local and unsafe destination addresses.
- Browser-rendering services are placed behind restricted networks and controlled egress.
- Redirects, response size, time budgets and request concurrency are bounded.
- Customer-supplied authentication is restricted by plan and instruction; Haunt does not solve CAPTCHAs or bypass login walls.
- Failures are returned explicitly and do not consume credits under the published billing rules.
Request data handling
- TLS protects traffic in transit.
- Sensitive stored request fields use application-level encryption where stated.
- Fetched page content is not stored as a page archive. Results are retained only for opt-in caching, up to 24 hours.
- Submitted URLs and prompts may remain encrypted for up to 60 days. Individual website funnel events expire after 7 days.
- Backups and recovery procedures support availability, with access and use restricted to recovery needs.
The Privacy Policy gives the full retention and purpose details. Processor commitments appear in the DPA.
Detection and response
Haunt uses service health checks, bounded security logs, request IDs, rate limits and automated monitoring to identify failures and suspicious activity. Relevant events are investigated, contained and documented.
When Haunt acts as controller, a notifiable personal-data breach is reported to the ICO without undue delay and, where feasible, within 72 hours after awareness. Affected people are informed without undue delay where the breach is likely to create a high risk.
When Haunt acts as processor, the affected customer is notified without undue delay after Haunt becomes aware. Notification does not wait for a completed investigation; available details follow as they are confirmed.
Responsible disclosure
Send the affected URL or component, steps to reproduce, observed impact and a safe contact address. Use a test account and the minimum activity needed to demonstrate the issue.
Do not use social engineering, denial of service, destructive testing, persistence, automated high-volume scanning, or access to data that is not yours. Stop and report immediately if another person’s data becomes visible.
Haunt will acknowledge a credible report, investigate it, and provide progress where practical. Public disclosure should wait until a fix is available and a reasonable remediation period has passed.
Shared responsibility
Customers must protect API keys, control their users, submit only authorised targets and personal data, review extraction output, and revoke credentials after suspected exposure.
Current providers are listed on the Subprocessor page. Security questions go to support@hauntapi.com.