Public REST (-inspired) API. Should I skip numeric IDs because it's easy for consumers to snoop around?

Example:

POST api/foo
201 Created api/foo/69

Uh, I'll get 68 just because I can. Hopefully it returns Unauthorized, unless we some kind of bug.

Is it just security by obscurity if I use, like, guids or something instead of sequental IDs?

Normally I’d expose UDID for ids, but it depends on your use case

@PappyHans I just need to uniquely identify a resource, I guess. Integers are used in the examples I've seen but I don't like that it's easy to snoop about.

I might convince the CTO to use GUID as primary key and just expose those in the url. Seems simple enough.

edit: together will real security measures of course, but with our track record so far there will be gaping holes.

Use sequential integers and say "Come at me bro!" to those that try to snoop. Then implement IP- or cookie-based snoop detection just to fuck with 'em.

Yes I normally use UUIDs

They reduce the guessing drastically if that’s your concern.

Here is the standard
https://en.m.wikipedia.org/wiki/...

@TheyCallMeMJ Someone pointed out that sequential IDs leak some info about how much usage that feature is getting. That might actually be important in this case.

@PappyHans Cool, we're on the same page now. Your first comment had a typo (UDID) which threw me off. Thanks for the reply. I call UUIDs GUIDs because I'm Microsoft-damaged.

Don’t make GUID the primary key in your database. You will hate yourself at scale (even a small one).

UDID (unique device id) is actually a thing :) its an iOS device id. I caught the error but was too late to edit.

@bkwilliams Aaw, how come?

@PappyHans Yeah I tried understanding how the device ID could be used. Nearly fried my brain.

@ihatecomputers GUIDs (being basically random but unique) are not sequential and some stacks will take longer to deal with non sequential PKs like INTs or BIGINTs. VARCHAR/CHAR have the same issue. But again, depends on the stack.

yes, good idea if you have per user private data.

Yeah, I use a UUID field in my data models and expose that so I keep my DB pk/ID field hidden

It's safe to use sequential IDs for data that doesn't matter, like comments, articles, whatever. You can make an argument for data behind auth walls, but it's good practice to use non-sequentials for everything sensitive.

An example of non-sequential IDs are hex strings. I recommend prefixes to quickly identify what type of ID it is, and to prevent accidentally using them in the wrong place. An invoice ID, for example, could be INV-ABCD1234. It's very obvious that isn't e.g. a salesorder ID.

If I can access something I should not by someone sending me a link then you/they need to fix that.

Like company A get hacked and their proxy logs get out. Someone goes through the logs and scrapes your API.

So you should use int and put proper authentication (sorry)

I say avoid any sequential ids for urls that you can simply because scripted bots will just run through them like a cat pulling the sheets off a toilet paper roll. If nothing else use some alphanumeric reversible symmetric hash if you don’t want the length of a true uuid. Look at YouTube at their v= url segment and you can see the mileage you can get with something like that. Also you don’t want to give up that kind of insider business stats like how many users you have, number of pages or the number of comments (ie engagement) you have relative to that number.