'123456' password exposed chats for 64M McDonald's job applicants

It sounds like there were two separate problems:

The first was that 123456 was the credentials for the admin panel.

The second was an insecure direct object reference, where the lead_id querystring parameter can be changed on an API call to retrieve another applicant's data.

A third problem that senior engineers might recognize: using numeric IDs on an outward facing object. UUIDs would have made this impossible as well

Ok, this is probably a stupid, very bad, no good idea considering I've not heard of people doing this, but can't you retain many of the benefits of numerical IDs but also the secrecy of UUIDs by using an HMAC ?

With HMAC, you can still ask for some sequential IDs

SipHash128(0, KEY) = k_0

SipHash128(1, KEY) = k_1

You get the same number of bits as a UUID.

You can't, however, sort by IDs to get their insertion sequence, however. For that you'd need something like symmetric encryption but this is already a bad idea, no reason to make it worse.

You could also "just" have an internal-use only numeric ID, or use a UUIDv7.

or ULIDs or any other partially sortable ids.

ULID are not necessarily sortable, just UUIDs consensed in a shorter string by using more characters than 0-9A-F