Sequential is still bad if you don’t want to disclose the size of your customer base or other commercially sensitive information.

Also see the German Tank Problem[1].

1. https://en.m.wikipedia.org/wiki/German_tank_problem

Am aware. Still don’t think it’s worth the hassle for most situations. Can leak information, but context is really important. I have rarely seen it be an issue over many years of app assessments. Just something to keep in the threat model for when it’s relevant.

There was one wireless ISP many years ago in a city I lived in that had a signal/reception page to see your signal to their closet tower. The URL included the customer number to identify your location. I quickly discovered it had no authorisation checks. You could easily find the exact addresses of all of their customers. Inactive/old customers returned no data.

What hassle is it? Where in your codebase do you assume sequentiality? It should be a one line change in your db configs to generate GUIDs instead of ids. You have to do it eventually anyway as sequentiality can't be assumed once you shard.

Depends on the needs I suppose. I don’t like starting off with GUIDs until it’s proven they are needed, because, as you say, it’s a simple change. Sharing does complicate the picture, but how many apps really need sharding.

> I don’t like starting off with GUIDs until it’s proven they are needed

For security incidents, "when they are needed" will be too late to do anything. If it's all the same to you, I'd advise that you default to GUIDs.

true, but if you do sequential for users and free trials, the information leakage can be close to zero. Think about if all those AOL CDs were sequentially numbered.

That's not zero information leakage. That's just leaking another statistic that is somewhat correlated to the one you want to hide (you're leaking the production of trial AOL CDs, and production of trial AOL CDs have some correlation to number of new users).

Don’t return indexes with user queries.

Usually you need some external unique identifier so you can interact with the object. Sure, that doesn't have to be the db index, but it is the convenient choice

Except when you want to change databases, or grow beyond a single one, or shard what you have. If you do this you’re binding your future self.

If you follow the "defense in depth" paradigm, then sequential identifiers bad when the other controls are defeated. Sequential ID make it trivial to crawl the entire dataset - which could be the difference between "Information on 4 million users was stolen" and "information from 4 users was stolen"