In the modern API security landscape, the JA4 Fingerprint has become a very useful tool. This fingerprint can only be generated on the proxy which is receiving the requests from the client, therefore it is normal practise for modern proxies (Such as Cloudflare, Azure Front Door) to append the clients JA4 Fingerprint as a header on requests.
As we must use App Proxy to call our API (We cant direct calls through our own proxy), we must receive the JA4 Fingerprint from the proxy. The JA4 Fingerprint is an important tool in any modern day API protection.
Previously, before Shopify unfortunately removed all the headers which contain ‘shopify’ attached to App Proxy requests ( Missing Shopify-Ipgeo-Country and X-Shopify-Client-IP in app proxy requests? ), requests were always appended with the header shopify-ua-ja4 which was the JA4 Fingerprint. Therefore please bring back a JA4 header on all App Proxy Requests.
Hey agaim @Drew_Loynes - thanks for flagging this too. shopify-ua-ja4 isn’t currently part of the documented App Proxy request contract, and App Proxy doesn’t currently expose a documented JA4 equivalent as you mentioned.
For now, I’d recommend combining X-Forwarded-For with App Proxy signature validation, request/customer-level rate limits, and application-level behavioural signals. These aren’t a direct replacement for JA4, but they’re the supported options available through App Proxy today (like I mentioned in that other thread, I get how this isn’t ideal).
I’m happy to pass this along as a feature request. Could you confirm whether you primarily use JA4 for blocking, risk scoring, or rate limiting? That context would be helpful on our end - thanks!
My request here is for Shopify to forward the JA4 Fingerprint again on App Proxy requests. (I maybe naively assume this can’t be much work here as the shopify-ua-ja4 header used to exist on requests).
We have an API which can proxy through us or through Shopify for our Shopify customers. With the modern security landscape our API protection includes many layers, most of which we have solutions for through the App Proxy apart from getting the client’s JA4 Fingerprint. The JA4 is used like other methods of assisting in identify suspicious scripted traffic, with the possibility of making decisions such as blocking, rate limiting or other decisions for certain scenarios in order to ensure the security of our API and data.
To the best of my understanding (Apologies if I’m completely wrong here), App Proxy must be used if theme extensions are fetching data through Shopify storefronts? If that is true it would be great to see Shopify to take this role seriously for their App’s APIs, as in this role Shopify is akin to Cloudflare. This includes providing the necessary client security information to Apps that Shopify would expect from other proxy providers such as Cloudflare.
Is there a specific Shopify or App Store requirement preventing your theme extension from calling your proxy directly using CORS?
I might be completely wrong here, but I thought I remember reading somewhere that as an App with a theme extension which calls our API, that we must use Shopify’s app proxy. Apologies if thats incorrect.
If CORS inside the theme extension is fine, the other difficulty here for us would be infrastructure. It is important for us to validate the shop which is calling our API, which the App Proxy handles very nicely. It would be a very big task for us to create a system for our Shopify customers which:
Automatically setup Shopify customers up with authentication on our API.
Provide a service for token generation for Shopify customers.
Update the theme extension to handle this new architecture.
That would be a large amount of work for our team.
Roughly what security impact has losing JA4 caused, and would an equivalent risk signal work, or do you specifically need raw JA4?
The JA4 is used across our backend API (Which handles Shopify and non-Shopify requests) to assist in identifying and handling security threats. Therefore this impacts our ability and effectiveness at identifying and handling security incidents across our API.
(Apologies this is the amount of detail I can provide on a public forum).
A direct request to your own endpoint is technically an option with CORS and your own authentication, but I definitely get why that isn’t a practical replacement here. App Proxy already provides the signed shop/customer context your integration relies on, so moving away from it would mean rebuilding that trust layer.
I’ve logged the request on our end with your latest details, here, but since there isn’t a supported JA4 field in the current App Proxy contract, there isn’t a configuration change I can point you to today.
I can’t guarantee a change or timeline, but I’ll keep you in the loop if there’s anything further I can share. Appreciate you flagging this.
Hey @Drew_Loynes - I was able to confirm a bit more on our end here. The shopify-ua-ja4 header wasn’t intentionally forwarded as part of App Proxy requests, and it was removed for security reasons. Because of that, restoring the raw JA4 value isn’t something I can point to as a supported option today.
I’ve passed along your feedback though, including that you specifically need the raw client JA4 for risk scoring, blocking, and rate limiting. I can’t guarantee a change or timeline, but it is something we’re taking into consideration.
I definitely get that this leaves a gap compared with your non-Shopify proxy traffic. Let me know if I can clarify anything further on our end here.
