Selected finding
Identifier-like values observed across domains
Benchmark frequency is directional market context only. It is not a compliance benchmark, legal conclusion, or severity score. Rare findings may be top-ranked only when retained evidence is strong; common findings may remain medium when evidence is automated or context-dependent. Rarity is not severity, and prevalence is not compliance risk.
Observed
Retained outbound request evidence showed identifier-like keys or values moving to a different domain or third-party context within the observed scan scope.
Why this matters
Identifier-like values in cross-domain requests can be relevant to tracking, attribution, advertising, analytics, identity, and vendor-governance review. For review teams, this signal can help identify where browser-visible data flows may warrant review for purpose, consent state, disclosure, contract, minimization, and vendor-governance context.
Detection methodology
CertScore inspects retained outbound request evidence for identifier-like keys, redacted values, destination domains, request origin/path, third-party context, vendor/category classification, timing, and consent context where available. This finding is surfaced when retained evidence shows identifier-like data in an outbound request to a different domain or third-party context within the observed scan scope. CertScore treats cross-domain identifier-sharing evidence as a review signal. The scanner does not determine personal identity, identity resolution, legal status, consent validity, sale/share status, or compliance status. Reviewers should consider whether the value is pseudonymous, hashed, scoped, session-only, security-related, analytics-related, advertising-related, or otherwise necessary, and whether the retained evidence is sufficient for the intended review.
Confidence semantics: Good when retained outbound request evidence includes request origin and path, destination domain, identifier-like key or redacted value pattern, timing, vendor or category classification, and enough context for reviewer inspection; stronger when retained evidence also includes repeated examples, consent timing, source and destination context, stable runtime anchors, and usable coverage. Manual review is still needed for purpose, identifier scope, identity-resolution risk, consent state, server-side behavior, and remediation quality.
Top-finding calibrationWhat must be retained to surface, top-rank, demote, or suppress this finding.
Minimum to surface
- Identifier-like key/value pattern in outbound cross-domain request.
High confidence requires
- Source/destination plus redacted key and vendor/category.
Top ranking requires
- Persistent or scoped identifier to adtech/identity destination or pre-consent/post-reject timing.
Demote or suppress when
- Generic query key.
- Destination unknown.
- Unredacted identifiers.
These rules describe ranking calibration for already-projected findings. They do not create findings from raw signals.
Example evidence
Cross-domain identifier request example
artifact=req_004role=finding_supporting_artifacturl=https://example.com/initiator_origin=https://example.comdestination_origin=https://measure.examplerequest_path=/collect [query_redacted=true]third_party_context=trueidentifier_like_keys=client_id, campaign_id [values_redacted=true]timestamp_ms=3180vendor_category=analytics_or_ad_measurementreview_caveat=manual review should confirm purpose, identifier scope, consent timing, destination role, and whether the value is pseudonymous, scoped, hashed, or otherwise limited
Review context
possible_flow=analytics_attribution_or_ad_measurementsource_domain=example.comdestination_domain=measure.exampleidentifier_values_redacted=trueconsent_timing_context=manual_review_recommendedmanual_review_needed=true
What should not count by itself
third_party_request_present=true [insufficient_without_identifier_signal]vendor=Example Measurement [insufficient_without_request_anchor]cookie_present=true [audit_only_without_outbound_transfer]query_key=id [insufficient_without_origin_destination_context]
View redacted sample JSONHide redacted sample JSON
{
"findingId": "cross_domain_identifier_sharing_observed",
"label": "Identifier-like values observed across domains",
"category": "Third-party tracking",
"criticality": "high",
"evidenceConfidence": "review_signal",
"directVsInferred": "direct_observation",
"evidence": {
"summary": "Retained outbound request evidence showed identifier-like keys or values moving to a different domain or third-party context within the observed scan scope.",
"examples": [
{
"title": "Cross-domain identifier request example",
"lines": [
"artifact=req_004",
"role=finding_supporting_artifact",
"url=https://example.com/",
"initiator_origin=https://example.com",
"destination_origin=https://measure.example",
"request_path=/collect [query_redacted=true]",
"third_party_context=true",
"identifier_like_keys=client_id, campaign_id [values_redacted=true]",
"timestamp_ms=3180",
"vendor_category=analytics_or_ad_measurement",
"review_caveat=manual review should confirm purpose, identifier scope, consent timing, destination role, and whether the value is pseudonymous, scoped, hashed, or otherwise limited"
]
},
{
"title": "Review context",
"lines": [
"possible_flow=analytics_attribution_or_ad_measurement",
"source_domain=example.com",
"destination_domain=measure.example",
"identifier_values_redacted=true",
"consent_timing_context=manual_review_recommended",
"manual_review_needed=true"
]
},
{
"title": "What should not count by itself",
"lines": [
"third_party_request_present=true [insufficient_without_identifier_signal]",
"vendor=Example Measurement [insufficient_without_request_anchor]",
"cookie_present=true [audit_only_without_outbound_transfer]",
"query_key=id [insufficient_without_origin_destination_context]"
]
}
]
}
}Regulatory review context
Cross-domain identifier sharing review
Retained outbound request evidence showed identifier-like cross-domain request patterns that may be relevant to tracking, advertising, analytics, attribution, consent, transparency, sale/share, and vendor-governance review. Applicability depends on identifier scope, purpose, destination role, consent state, jurisdiction, server-side behavior, and manual review.
View applicability notes
Legal and regulatory frameworks
- GDPR online identifier reviewCookie IDs, IP addresses, device IDs, or other online identifiers may require review where they could relate to an identified or identifiable person.
- GDPR transparency and third-party disclosure reviewRetained evidence suggests identifiers may move to third-party analytics, advertising, attribution, or identity partners.
- ePrivacy cookie/device identifier reviewIdentifier-sharing review may be relevant where cookies, browser storage, redirects, or terminal-equipment information are involved.
Jurisdictional contexts
- EU GDPR/ePrivacy identifier sharing reviewEU/EEA users, online identifiers, profiling, cookies, or third-party sharing may be in scope depending on purpose, consent state, jurisdictional context, and manual review.
- CCPA/CPRA sale/share and cross-context behavioral advertising reviewCalifornia users and identifier-like request signals may be relevant to advertising, identity matching, attribution, sale/share, or cross-context behavioral advertising review depending on purpose, vendor role, user region, and manual review.
- FTC privacy representation reviewRuntime sharing may conflict with privacy disclosures, consent promises, or data-sharing statements.
This finding does not determine legal status, personal identity, identity resolution, sale/share status, consent validity, or compliance status. Review the retained request anchors, redacted identifier-like keys, source and destination context, vendor purpose, consent timing, regional configuration, and applicable exemptions.
Evidence standard
Strong
- Retained outbound request evidence includes origin and path, destination domain, timestamp, and redacted identifier-like key or value pattern.
- Evidence shows the destination is a different domain or third-party context.
- Evidence includes vendor or category classification, purpose context, or request pattern sufficient for reviewer inspection.
- Evidence redacts or omits full identifier values, query strings, and payloads.
- Coverage context indicates request ordering and retained anchors were not materially blocked or unreliable.
Good
- Retained request evidence shows identifier-like data sent cross-domain, but purpose, identifier scope, or vendor classification is less complete.
- The retained example is enough for a reviewer to inspect origin and path, destination, redacted key or value, and timing manually.
- The evidence is likely a cross-domain identifier-sharing review signal, but identity-resolution risk, consent relevance, server-side behavior, and legal significance require manual review.
Audit-only
- Third-party request observed, but no identifier-like key or value pattern is retained.
- Identifier-like key appears in a request, but destination, timing, or context is incomplete.
- Vendor registry or policy text suggests sharing, but no retained outbound request artifact supports the observed state.
Insufficient
- Third-party request alone.
- Vendor name alone.
- Generic query string without identifier-like signal.
- Cookie presence without evidence of outbound cross-domain transfer.
- Identifier-like key without request origin, path, and destination context.
- Unredacted identifier values in public examples.
- Claims about personal identity, identity graph, legal status, sale or share status, compliance status, or tracking lawfulness based only on automated evidence.
Evidence levels explain how CertScore treats retained runtime artifacts. They are not legal conclusions.
Common causes
- Analytics or advertising requests include client, session, campaign, or device identifiers.
- Attribution or measurement SDKs append persistent IDs to outbound requests.
- Identity, data platform, or tag-manager integrations pass pseudonymous IDs across domains.
- Redirect or pixel flows include identifier-like parameters.
- Consent, regional, or minimization settings do not suppress identifier-like parameters before transmission.
Recommended review questions
- Which outbound request carried the identifier-like key or value?
- What was the source origin and destination origin?
- Which query keys or parameter names were retained, and were values redacted or hashed?
- Is the value likely session-scoped, client-scoped, device-scoped, campaign-scoped, hashed, pseudonymous, or otherwise limited?
- What vendor/category or endpoint purpose is associated with the destination?
- Did the request occur before consent, after consent, after reject, or outside known consent context?
- Could the value support analytics, attribution, fraud prevention, security, advertising, or another purpose?
- Is the behavior browser-visible only, or might relevant server-side sharing be outside scan scope?
- Are query strings, identifiers, cookie values, and payloads redacted while preserving stable anchors?
Limitations and cautions
- This finding is an automated cross-domain identifier-sharing review signal, not a legal conclusion, certification, compliance determination, sale/share determination, or determination of tracking lawfulness.
- Automated request evidence can identify identifier-like keys or value patterns, but it does not determine personal identity, identity resolution, or a complete identity graph.
- Identifier-like values may be pseudonymous, scoped, hashed, session-only, campaign-related, security-related, or otherwise limited.
- Some cross-domain requests may support analytics, attribution, fraud prevention, security, service delivery, or other context-dependent purposes.
- Server-side sharing, partner-side processing, and downstream data use may not be visible to a browser scan.
- Consent timing, jurisdiction, vendor purpose, and applicable exemptions require manual review.
- CertScore redacts or avoids retaining full query strings, identifiers, cookie values, and sensitive payloads while preserving stable anchors needed for review.
- Automated findings may contain errors and should be reviewed with the retained evidence.
- Not detected means not observed in the scan scope; it is not proof of absence.
- Findings are runtime evidence and public-surface observations for review, not legal conclusions.
