Security and privacy

Protect credentials

Keep Data API and Browser Workflow API keys on a trusted server, worker, or CI secret store. Do not put long-lived keys in browser bundles, URLs, query parameters, analytics, logs, or error reports. The Console shows newly created secrets only once.

Headers and cookies inside a scrape request belong to the target site. They are not a second way to authenticate RunHarvester. Never forward a RunHarvester API key to the target site through request headers or cookies.

For credential rotation and scopes, see Authentication.

Browser requests and CORS

The API playground sends requests directly from the browser to the public API; the documentation site does not proxy them. CORS controls whether browser code may read a response, but it does not protect an API key embedded in that browser code.

For a deliberate browser integration, allow only the origins you need and use the API's header-based authentication. Do not send credentials: "include" with a wildcard CORS policy. For production integrations, keep the key on your backend and let the browser call your own server.

Retention and returned data

Public request DTOs expose safe status and billing metadata, but do not return full target paths or query values, request headers or cookies, proxy endpoints or credentials, API-key secrets, provider keys, or CAPTCHA solutions.

Treat target content and credentials as sensitive before submitting them. Redact them from logs and support requests, and use the documented result retention window when designing storage.

Preview HTML safely

result.html is target-controlled content. Do not inject it into your application's main origin. If you need a visual preview, use a sandboxed iframe without allow-same-origin or allow-scripts; otherwise show the HTML as text or code.