The Codes the Page Had To Know: What a Browser Check Has To Be Told
The challenge
Brightloom's checkout checks your discount code in the browser before it bothers the server, so that a customer who mistypes one gets told immediately. To do that it has to know every code, and to know every code it has to be sent every code. The banner advertises one of them. The page is carrying five, with their dates and their percentages, and one of them is live today and was never meant to leave the warehouse. Name it.
What you'll learn
- Recognise that client-side validation requires shipping the data validated against
- Read a packed record list out of a hidden form field
- Eliminate candidates using dates supplied by the page itself
- Identify which entry has no server-side eligibility check and why
- Explain why a hidden field is a publication, not a secret
Skills tested
Prerequisites
- What an HTML form and a hidden input are
How it works
Validating input in the browser is good for users. A customer who mistypes a code should be told instantly instead of waiting on a round trip. The catch is structural rather than accidental: to check an answer, the checker needs the answer, so a page that can tell you a code is invalid has been given every code that is valid.
That is true of every client-side check of this shape. Allowed file types, blocked email domains, minimum order values per region, which features belong to which plan: if the page decides, the page knows. Hiding the field changes nothing. A hidden input is not encrypted, not read-only and not private, it is simply not painted, and View source shows it in full.
The second half is the one that costs money. The comment explains that customer codes are re-checked against the order server-side, while staff codes are accepted on the code alone because in-store handhelds have no customer to check against. That exception is defensible in the warehouse and indefensible on a public checkout, and shipping the list to the web client is what connected the two.
Common mistakes
- Answering AUTUMN15. It is live, and it is advertised in the banner at the top of the page. Nothing was disclosed.
- Answering YULE30. Forty is not the biggest number here, thirty is next, but its window starts on 1 December.
- Answering SPRING10. Expired on 30 June.
- Answering WELCOME5. In window, but the page records
customer_typeas returning, and the API checks customer codes against the order. - Using your own clock. The page ships the server's date in a hidden field. Use it.
How to defend against it
Check on the server, and give the client only what it needs to ask.
- Validate the code with a request. If instant feedback matters, send the typed code to an endpoint that answers valid or not for this order, and return nothing else.
- If a prefilter is genuinely wanted, ship only the codes that are already public. Internal and staff codes should never reach a web client, which is exactly what the ticket in the comment says.
- Remove the exception rather than the disclosure. A staff code accepted on the code alone is a bearer credential; bind it to an authenticated staff session or a registered terminal.
- Rate limit redemption attempts and alert on a code used outside the channel it belongs to. A warehouse code redeemed on the public checkout is a one-line alert.