← All checks
Compliance & Privacymediumdevice-fingerprinting-script

Recognised device-fingerprinting provider reference in static page evidence

ShipReady found a recognised FingerprintJS or Fingerprint.com signature in the static page evidence it inspects.

Why it matters

A recognised fingerprinting-provider reference is worth reviewing because provider configuration and loading conditions determine how the integration is used in the deployed product.

How ShipReady detects it

What it inspects

ShipReady reads fetch-bearing HTML attributes and executable inline script or style content from the fetched page, looking for supported FingerprintJS and Fingerprint.com signatures.

What triggers a finding

The rule triggers when a supported fingerprinting-provider signature appears in those static evidence regions.

What the evidence shows

The evidence proves that ShipReady found a recognised fingerprinting-provider signature in the static page evidence and identifies the matched provider.

Limits of this check

ShipReady does not execute the provider code or inspect provider configuration, API calls, fingerprint output, browser characteristics, stored identifiers, or network traffic. It does not prove a fingerprint was generated, that a visitor was uniquely identified, or that tracking or personal-data transmission occurred. Prose and navigational links do not trigger this rule.

How to fix it

Confirm the intended use

Identify the code path that adds the reported provider and document the product purpose it serves.

Review provider and runtime configuration

Review the deployed provider settings, API usage, storage behavior, and loading conditions against the product's intended design.

Limit the integration to needed flows

If the provider is necessary only for a specific flow, ensure the application loads it only where that flow needs it.

How to verify the change

Verify behavior in the deployed application

Use browser developer tools and the provider dashboard or configuration to inspect the actual integration behavior on the flows where it is intended to run.

Expected: The provider is absent where it is not needed, and the reviewed runtime configuration matches the product's intended use.