FP FINGERPRINT

Security and Privacy

Fingerprint.dev handles data that can help recognize a device or browser over time. Treat that data carefully in your own systems.

What the service returns

Identify responses contain aggregated hashes and IDs:

  • visitor_id
  • request_id
  • confidence
  • JA4-family connection hashes when available
  • Combined and per-axis JavaScript signal hashes when browser evidence is sent

These values are designed for matching and investigation. They are not account credentials.

Browser signal handling

The JavaScript SDK collects optional browser signals and hashes present values locally before sending them to the API. If a signal is blocked or unavailable, it is represented as null.

Do not store raw browser signal values. Do not place raw values in local storage, analytics events, error reports, or application logs.

API keys

API keys are credentials. Store server keys in secret management and keep browser keys scoped with allowed origins.

Operational rules:

  • Use different keys for development, staging, and production.
  • Revoke keys that are no longer used.
  • Rotate keys when ownership changes.
  • Do not log raw key values.
  • Show only key prefixes in support tickets and shared screenshots.

Production logging

Safe fields to log in your application:

  • visitor_id
  • request_id
  • confidence
  • Request outcome and latency

Avoid logging:

  • Raw API keys.
  • Raw browser signal values.
  • Full request or response bodies if they include fingerprint payloads.
  • User-provided metadata attached to your own risk events unless your privacy policy covers it.

User experience

Fingerprint.dev does not authenticate users. Use it as risk and recognition evidence alongside your own account, session, and authorization systems.