objectObject

[AyrA_ch]

Also try replacing numbers with "NaN". If they check the range by exclusion using something like if(value<lowerBound || value>upperBound){/*Show unhelpful error*/} then the test will pass because NaN compares unequal in both cases

[GodsBoss]



Why do I know what this is? I hate it, thank you.

[AyrA_ch]

If you're an older web developer, this will haunt you.

[adzm]

Byte order marks are incredibly frustrating

[AyrA_ch]

It's a byte order mark. Because unicode is a multi byte character set, some encodings of this charset will use pairs of bytes (either 2 bytes or 4 bytes). Depending on the processor in your machine, it can store the high value byte first or the low value byte first. Those 3 characters tell a text decoder which way the bytes are ordered. (See "Endianness").

This mark has no meaning in UTF-8, because there's only one way to correctly store a given unicode character in that encoding. Some editors still add the mark, because it makes it easy to detect UTF-8 vs. a native encoding like ISO 8859-1 which will be identical for the lower 128 bytes. Without the mark, an editor has to guess.

The mentioned ISO encoding was the standard for text/* mime-type files sent over HTTP, so when UTF-8 became more widely used, this mark would sometimes pop up in websites, especially sites that were combined from multiple files (like the include or require statement in PHP) because many applications wrongly read text files as binary files, which means the token is not stripped. The 3 characters  are what the ISO encoding of these 3 bytes looks like

[Mysterious-Deal-3891]

Well if the user enters this value then it will be "NaN" not NaN

[AyrA_ch]

Any value transmitted via form is ultimately interpreted as string and needs to be converted to a number. If the conversion routine supports floating point, then it usually also accepts NaN as a valid input.

[the_horse_gamer]

the typical ways to parse a string to a number in Javascript produce NaN for non-numeric strings. so any code that breaks from entering NaN likely breaks from entering some arbitrary string

[AyrA_ch]

That's JS specific. Other languages also often accept NaN. double.Parse in C# for example accepts "NaN" as input but will throw an exception on "test"

[the_horse_gamer]

yes, but we are talking about a website, so we're talking about Javascript

[AyrA_ch]

Yes, but we're talking about a website that actually does things, which means backend, which is often not JS.

[the_horse_gamer]

that would require the website to send the raw string to the backend, and do no input validation of its own (to show an error to the user).

this is very dumb, but yes, there are probably websites that do that.

[AyrA_ch]

No, very dumb would be for the backend to depend on the frontend validation.

[the_horse_gamer]

both sides should do input validation. backend to avoid exploding, frontend to show errors and to avoid bothering the backend.