These damn incremental aids

As a programmer who participated in the development of payment systems, I repeatedly had to analyze for the presence of vulnerabilities various payment services that store personal data of clients and I constantly encounter one very common problem. The name of this problem is incremental aids.

Example number 1.
The site of the largest aggregator of payment methods in Russia, serves the leader of online games. After payment of the order redirects the client to the URL of the form aggregator-domain/ok.php?payment_id=123456 aggregator-domain/ok.php?payment_id=123456 , which in turn redirects to the online game site with the address of the form (decoded for readability) online-game-domain/shop/?...amount=32.86...¤cy=RUB...&user=user_email@gmail.com...&item_name=1 ...
Going payment_id values ​​of the payment_id parameter, we can see the logins of users in an online game, the purchases they made, their sum.



Example number 2.
On one of the actively advertised sites for issuing online loans after filling out a form with personal data, the result of the generated application was issued by the link domain/confirmation?clientId=12345 domain/confirmation?clientId=12345 , where, during a GET request, in addition to everything, the full name, residential address, taxpayer identification number were returned.
These data had to be transferred to the client in order to form an invoice for payment through the bank's cash office. But if we clientId over the values ​​of the clientId parameter, we received the personal data of other clients.
')


Example number 3.
Internet bank of one of the largest banks in the country. When forming a regular payment, an incremental ID was assigned to it and, by POST request, to the address of the form domain/calendar_event.php domain/calendar_event.php with the id=12345 parameter returned detailed information about the created regular payment, including the user's full name, card numbers, payment amount, purpose, regularity. And again, when the id parameter was changed in a smaller or larger direction, we got access to the private information of other clients.



Example number 4.
Quite popular chat for sites. The account had settings, dialog history, administration of operators, etc.
The session ID was sessionID=”12345|6749476c44696255216a6148516d5e33”
where the first part is the company identifier, the second is the user identifier.
As a result, when changing the first identifier, we got into the admin panel of a completely foreign company. Having access to the account, we had the opportunity to add operators and engage in dialogue with customers on behalf of the campaign.



Conclusion:
In the examples above, due to programmer errors, the potential for personal data leakage was allowed. This is a great price for the convenience of using an integer identifier.
What to do? Use a token. An arbitrary string of even a small length will protect you from busting and mass theft of information. After all, you cannot protect yourself from programmer errors, and the code that is built on the use of incremental identifiers will have to be constantly monitored

PS
I agree with the comments and add from myself:
Using a token is only suitable as an additional level of security; full protection should be implemented in the application architecture through a system of rights and access.