Which way to pass the fingerprint to the server?

[sneko]

Hi,

I didn't find any mention about this but: what do you advise to pass the fingerprint from the frontend app to the backend API?

• By a POST data form, but I don't want that, it's too related to the mutation request
• By a header
• By a cookie

I thought about using a header? What do you think?

And if that's also what you recommend, which HTTP Header naming do you use? X-Fingerprint?

Thank you,

[sneko]

Curious to know your thoughts @Valve @Finesse ?

Thank you,

[makma]

Hi @sneko ,
I believe this question has been already answered in this discussion.
Please let me know if you have any additional questions.

Note: Open-source library FingerprintJS is designed to deal with regular users, not tech savvy folks. It's simple to forge headers (custom or cookie) using devtools or (local) proxy tools.

[sneko]

@makma unfortunately the mentioned discussion speaks about "improving the way to know the fingerprint is not tampered". Whereas my question is more to know if there is a common way to pass the fingerprint to the backend. More precisely, to know in case of HTTP header which naming you use (to avoid conflicts with other tools, but also to maybe hide a bit this functionality).

(about the your note, I do know it can be tampered and that and additional check should be made on the backend side when using the Pro version 😄 )

[makma]

Thanks for the clarification, @sneko.

Whereas my question is more to know if there is a common way to pass the fingerprint to the backend.

Usually, (for example in protecting login scenario), this data is sent together with credentials in the body (or in a custom header).

More precisely, to know in case of HTTP header which naming you use (to avoid conflicts with other tools, but also to maybe hide a bit this functionality).

I'm not sure I understand, open-source FingerprintJS does not send any requests (therefore, there are no headers).

Requests for FingerprintJS Pro are crafted in our JS agent. It doesn't matter what header you want to use in your custom requests to your backend.

You can use some kind of obfuscation together with client-side encryption but this is more like a countermeasure against script kiddies. There's no way to ensure the request was not changed.

[sneko]

@makma my point was:

• FingerprintJS OS or Pro generates a fingerprint on the frontend
• Depending on the need: the frontend passes the data to the backend for additional checks (either on the fingerprint directly or the requestId) (in my case I need to verify it)
• If it was tampered, or not fulfilled, we can suspect this user from being "abnormal" (and maybe not accepting his requests)

So as you mentioned

(or in a custom header).

I was just curious of the naming, if X-Fingerprint for example is common or not in passing the fingerprint to the backend... (or maybe to expressive...).

[makma]

Hey @sneko

FingerprintJS OS or Pro generates a fingerprint on the frontend

No, this assumption is not correct. FingerprintJS Pro just collects information on the client side. visitorIds are generated on our backend.

Depending on the need: the frontend passes the data to the backend for additional checks (either on the fingerprint directly or the requestId) (in my case I need to verify it).

There's no out-of-the-box solution for fingerprint validation in open-source FingerprintJS.
For verifying visitorIds with FingerprintJS Pro, you can use server API or webhooks. You can use e.g. confidence score, requestId, and timestamps.

If it was tampered, or not fulfilled, we can suspect this user from being "abnormal" (and maybe not accepting his requests)

Yes, this is a common use case for FingerprintJS Pro and all visitorIds should be validated.

I was just curious of the naming, if X-Fingerprint for example is common or not in passing the fingerprint to the backend... (or maybe to expressive...).

Yes, it might be too expressive, I would use something more generic (metrics maybe). Nevertheless, this doesn't solve the initial concern. It's still some kind of obfuscation that's not bulletproof because of the client-side nature.