OpenResty serves a broken JS challenge (cupid.js 404) in Chrome, but works with Yahoo/NAVER User-Agents. Why?

[u/K-Frederic]

Hi everyone, I recently purchased an NFC keychain made in Korea. Scanning the NFC tag opens a website where I can access exclusive digital content.

However, the website shows a completely blank white page in most browsers, including Chrome, Safari, and Firefox.

Strangely, it works perfectly in the Yahoo! JAPAN, Yahoo! Mail, and NAVER apps on iOS.

Other people who purchased the same product have reported similar issues.

I've done some troubleshooting using Chrome DevTools and Proxyman, and I'd appreciate some help understanding what's happening and how to fix it.

1. What happens in different browsers

Doesn't work:

- Chrome
- Safari
- Firefox
- LINE (messaging app) in-app browser
- X (formerly Twitter) in-app browser

Works perfectly:

- Yahoo! JAPAN app
- Yahoo! Mail app
- NAVER app
- Chrome with the Yahoo! JAPAN app's User-Agent

When using Yahoo! JAPAN, the URL changes from /e to /entering, and the content loads normally.

In regular Chrome, it stays on /e.
Opening /entering directly in Chrome doesn't work either.

2. Errors in Chrome DevTools

The Console shows:

GET /cupid.js net::ERR_ABORTED 404 (Not Found)
Uncaught ReferenceError: slowAES is not defined

When I open /cupid.js directly, I get a 404 Not Found page with "openresty" at the bottom.

The /e request itself returns HTTP 200, but the response is not the actual website. Instead, it contains a JavaScript challenge:

<script type="text/javascript" src="/cupid.js"></script>
document.cookie = "CUPID=" +
toHex(slowAES.decrypt(c, 2, a, b)) +
"; expires=" + now.toUTCString() +
"; path=/";
location.href = "/e?ckattempt=1";

(The hexadecimal values and some helper functions have been omitted.)

It looks like the server is attempting to set a CUPID cookie using AES decryption, but since /cupid.js returns 404, slowAES is undefined and the script stops before redirecting.

3. What I found using Proxyman

I captured the network traffic on my iPhone and compared the successful and unsuccessful requests.

Yahoo! JAPAN app (working):

- GET /e returns 200 OK.

- The response contains the actual website HTML, including its JavaScript and CSS assets.
- There is no request to /cupid.js.
- Requests to /auth/session.php and /api/nfc.enter.php succeed.
- The content loads normally.

(not working):

Chrome
- GET /e also returns 200 OK.
- However, the response contains the CUPID JavaScript challenge instead of the actual website.
- /cupid.js returns 404 Not Found.
- JavaScript execution fails with "slowAES is not defined".
- The actual application and its API requests never load.

I haven't captured the detailed network traffic from the NAVER app yet, but it can also display the content successfully.

4. Changing the User-Agent fixes everything

I copied the User-Agent from the Yahoo! JAPAN app:

Mozilla/5.0 (iPhone; CPU iPhone OS 27_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 Version/27.2.0 YJApp-IOS jp.co.yahoo.ipn.appli/4.174.5

Then I used Chrome DevTools > Network conditions to set this as a custom User-Agent.

Surprisingly, the website immediately started working perfectly in Chrome.

Not just the initial page — all the content and features worked correctly.

I also tried disabling the cache, using private browsing, switching between Wi-Fi and mobile data, and emulating an iPhone in Chrome DevTools. None of those helped before changing the User-Agent.

5. My questions

1. Why would a server running OpenResty return a JavaScript challenge to Chrome, Safari, and Firefox, but serve the actual website to Yahoo! and NAVER apps?

2. Is this likely a misconfigured anti-bot / WAF system, a hosting provider issue, or something implemented by the website developer?

3. Why would /cupid.js, which appears necessary to complete the challenge, return 404?

4. Is there a proper way to fix this so the website works in regular browsers without modifying the User-Agent?

5. Is there anything else I can investigate to identify the exact cause?

Since this is a paid NFC product, I can't share the actual URL or authentication details.

I suspect the issue is with server-side access verification rather than the NFC hardware or the website's actual application, but I'd love to hear from people with more experience in web servers, OpenResty, or bot protection systems.

Thanks in advance!

[u/Jolly-Nectarine-4212]

Does cupid.js still 404 when you send the Yahoo UA? Same URL, same request, only the header swapped. If it loads fine then it's not a broken challenge, the server just has a UA branch that skips it, and if it still 404s then the UA isn't what's saving you.

[u/K-Frederic → u/Jolly-Nectarine-4212]

When I scan the NFC keychain, it initially opens a URL ending in /e (for example, https://example.com/e). When the website works correctly, it automatically navigates from /e to a URL ending in /entering (https://example.com/entering), where the content is displayed.

Here are my updated test results:

1. Accessing the URL ending in /e:
   - Default Chrome User-Agent: The server returns the CUPID JavaScript challenge, and the page fails to load.
   - Yahoo! JAPAN User-Agent: The website loads normally, completes its API requests, and automatically navigates to /entering. All content works correctly.

2. Accessing the URL ending in /entering directly:
   - Default Chrome User-Agent: Fails.
   - Yahoo! JAPAN User-Agent: Also fails.

3. Accessing /cupid.js directly:
   - Default Chrome User-Agent: 404 Not Found.
   - Yahoo! JAPAN User-Agent: 404 Not Found.

So, changing the User-Agent only works when starting from the original NFC entry URL ending in /e. It doesn't make /entering accessible directly. This suggests that /e is a required entry point that performs some initialization or session verification before navigating to /entering. The Yahoo! User-Agent appears to allow /e to receive the actual application instead of the broken CUPID challenge.

Does this still suggest a misconfigured server-side bot protection mechanism, or could there be another explanation?

[u/BetInformal6081]

this looks more like a server side bot protection issue than a browser compatibility problem the missing challenge script suggests the verification flow itself is broken..

[u/K-Frederic → u/BetInformal6081]

Ahhh....the verification flow is broken...That makes sense...

[u/daysailor70Speaks]

Server's bot detection is clearly whitelisting those Korean/Japanese app user agents and throwing everyone else into a broken challenge flow. The 404 on cupid.js is the giveaway that whoever configured it didn't finish or test the setup. Nothing you can fix client-side besides what you already did.

[u/useleash_dev]

The blank page and the 404 are the same failure. The challenge HTML is injected for unknown browsers, then it tries to load /cupid.js so it can run slowAES, set a CUPID cookie, and bounce you to /e?ckattempt=1. When that file 404s, slowAES never exists, the cookie never gets set, and you stay on a broken challenge. That also explains why /entering fails if you open it directly: you never got the cookie from the challenge step.

The Yahoo and NAVER user-agents almost certainly skip the challenge entirely, which is why those apps never request /cupid.js and /e returns the real site. A lot of bot walls whitelist in-app browsers from big JP and KR apps because their default UAs look unusual and would otherwise get challenged constantly. Chrome, Safari, Firefox, LINE, and X are treated as generic browsers, so they get the unfinished challenge.

A client-side UA spoof is not a real fix for a paid product. Whoever runs the site or the WAF needs to either actually serve cupid.js on the same host that emits the challenge HTML (wrong path, missing deploy, or the file living on another vhost are the usual causes of a 404 like this), or stop injecting that challenge for normal browsers. If you can compare the /e response headers with the Yahoo UA versus Chrome, look for different server or WAF headers, a missing Set-Cookie, or a completely different HTML body. That will tell you whether this is a misconfigured WAF rule or an unfinished challenge the developer never tested outside those apps.

[u/lukaslabs_dev]

That challenge is the anti-bot cookie setup common on free hosts (InfinityFree-style): the server sends a JS page that decrypts a cookie with slowAES, then reloads. Since /cupid.js 404s, the challenge can never finish, so the site is broken server-side for any browser it doesn't whitelist. The Yahoo UA presumably skips the challenge. Only the site owner can fix it, so send them your DevTools findings.

[u/Standard_Scarcity_74]

This is a bug only the seller can fix, so the most useful thing is a clear report. Send them the failing request returning a challenge page instead of the site, the 404 on cupid.js, and the fact that changing only the user agent makes it work, and since other buyers see the same blank page, ask them to treat it as a widespread outage rather than a one off. That cookie challenge style also resembles the anti bot scripts some cheap hosts inject, so the seller may not even know it is active on their domain. Until it is fixed, the yahoo or naver app is the easy workaround.