What Wordle's Source Code Teaches About Client-Side Secrets

A reader emailed me last month after a customer told her the discount code for next week's sale. The code had not been announced. The customer found it by opening the browser's developer tools on her shop and searching the page script for the word "discount". The site was not hacked. It had simply handed every visitor a file with the answer inside, and one curious visitor read it.

That is one of the most common security mistakes I see on small websites, and the clearest illustration of it is a word game that millions of people played every morning in early 2022.

The answer was in the file all along

Wordle was built by Josh Wardle and released to the public in October 2021. Its original version was beautifully simple: one web page, one JavaScript file, no login, no server doing any work beyond sending the files. That simplicity was a big part of why it could go from a few dozen players to millions within weeks without falling over. Static files are cheap and fast to serve, and a content delivery network can hand them out to the whole planet.

But the simplicity had a side effect. Every answer the game would ever use, a list of 2,315 words, sat inside that JavaScript file in order. The game picked the day's word by counting the days since its start date in June 2021 and reading that position from the list. Anyone who opened the script could scroll through the list and see the answer for any future date. People did exactly that, and spoiler accounts appeared on social media almost immediately.

When The New York Times bought Wordle in January 2022, for a price reported in the low seven figures, it inherited the same design. Later versions moved toward fetching each day's puzzle from a server on that day, which hides the future answers while keeping the page fast. Today's answer still reaches your browser, because the game needs it to colour your tiles. Tomorrow's does not.

Anything you send to the browser is public

This is the principle Wordle demonstrates, and it applies to every site. HTML, CSS, JavaScript, images, and any data your pages fetch all arrive on the visitor's device. Minifying a script makes it harder to read for a human in a hurry, but anyone with ten minutes and a search box can still find a string inside it. If you can see it in the Sources or Network tab of your browser's developer tools, so can everyone else.

On small business sites I review, the things that most often leak this way are:

• Discount and promo codes checked by a script in the browser instead of by the server at checkout.
• Secret API keys pasted into front end code. A Stripe key beginning with sk_live_ is a secret key and must never appear in the browser. The one beginning with pk_live_ is designed to be public.
• Hidden prices or stock levels included in a product data file and simply not displayed.
• Admin links that are "hidden" only because no menu points to them, but appear in the script's list of routes.

Not every key in front end code is a problem. Some services expect a public key and protect it in other ways. A Google Maps key, for example, is meant to be visible and should be restricted to your own domain in the Google Cloud console so nobody can reuse it elsewhere. Firebase configuration is also public by design, with the actual protection living in its security rules. The question to ask about any value is whether a stranger who copied it could do something you would not want them to.

Why "just obfuscate it" is not a fix

When people discover a leak like the discount code, the first suggestion they find online is usually to obfuscate the JavaScript, scrambling names and encoding strings so the file is unreadable. I understand the appeal. It is quick, there are free tools for it, and the next time you look at the file it seems safe.

It is not safe. The browser has to be able to run the code, which means the browser has to be able to recover the original values, which means a person can recover them too. Wordle's answer list could have been encoded, and players would have decoded it within a day, because the reward was worth a few minutes of effort. Your discount code is worth far more to a bargain hunter than a Wordle spoiler.

Obfuscation also has a performance cost, which matters to me more than most people. Heavily obfuscated scripts are often larger and slower to parse. On a mid range phone on a patchy 4G connection, that can add a noticeable delay before the page responds, and I have written before about why a fast website matters more than a fancy one. You end up paying in speed for protection you do not actually get.

The browser is the visitor's machine. Treat everything you send there as if you had printed it on the front of the page.

The real fix is to move the decision to the server. A discount code should be checked by your checkout system when the order is submitted. A secret key should live in your server's environment settings, and the browser should call your server, which then calls the third party service. That is exactly the shift Wordle made: the server decides what today's word is and only sends that one.

Keeping the speed while hiding the secrets

The good news is that you do not have to give up a fast, mostly static site to do this. Wordle's later design still sends a light page from a CDN and only makes one small request for the day's data. Many site builders and hosts now include small server functions that run your sensitive checks without you managing a full server. If you are not sure where your site's logic actually runs, our explainer on how websites actually work covers the split between browser and server in plain language.

Here is a 15 minute audit you can run this week, on your own site, without any special tools:

1. Open your home page and checkout page in Chrome or Firefox, then open developer tools with F12.
2. In the Sources tab, use the search across all files (Ctrl+Shift+F) and search for: key, secret, token, discount, coupon, password, and admin.
3. In the Network tab, reload the page and click through each JSON response. Look for prices, stock, emails, or codes you did not mean to publish.
4. For each match, ask whether a stranger could misuse it. If yes, note it down.
5. Send that list to whoever built your site, or work through it with the guide on keeping your website secure.

Most sites I check turn up nothing worrying. About one in five turns up something that is worth fixing the same day.