Niebezpieczna luka w systemie rejestracji na UJ.
Zakładasz dowolne konto, logujesz się i możesz przeszukiwać bazę danych kandydatów. Wystarczy, że w pasku wyszukiwarki zmienisz trzy ostatnie cyfry adresu.
Kontrola dostępu do danych się kłania. A identyfikatory globalne są ZŁE! (patrz Insecure Direct Object Reference oraz dobre wyjaśnienie ogólnej koncepcji AccessReferenceMap, że o moim PoC nie wspomnę).
Można też wyobrazić sobie bardziej złożone sytuacje, choćby wymuszanie kontroli dostępu do danych na poziomie WAF (co samo w sobie jest dość karkołomne). W normalnej sytuacji potrzebna jest informacja kto do czego się może dostać. W przypadku wspomnianych rozwiązań jeszcze potrzebna będzie informacja jakie te obiekty mają obecnie (w danej chwili) identyfikatory "tymczasowe", a mogą się one zmieniać w zasadzie z każdym requestem (a w moim PoC nawet w obrębie jednego requestu jeden obiekt może być "wskazywany" przez różne identyfikatory).
Pewnie dałoby się znaleźć kilka innych przypadków, ale zapewne ich pierwotną przyczyną będzie właśnie brak informacji o istniejącym w danej chwili mapowaniu identyfikator - obiekt.
Na marginesie - jeśli bardzo chcemy skrócić id to można je zakodować jako base64 zamiast gołego stringa szesnastkowego, da to ze 2 bity na bajcie zysku.