Kontrola dostępu do danych (do funkcji zresztą też) jest często realizowana wyłącznie na poziomie GUI. Oznacza to, że funkcja generująca stronę sprawdza, do jakich danych użytkownik ma dostęp. W niektórych przypadkach takie rozwiązanie może być wystarczające, jednak typowym scenariuszem jest przygotowanie w ten sposób listy elementów (np. listy tytułów, listy użytkowników, listy rachunków bankowych), na których użytkownik może wykonywać różne operacje, w szczególności może zażądać wyświetlenia szczegółów dotyczących danego obiektu/elementu. Programiści często zakładają, że jedynymi zdarzeniami, jakie jest w stanie wygenerować użytkownik są te, które pozwala wygenerować mu strona. Oczekują więc, że jeśli wypisane zostaną obiekty o określonych identyfikatorach (te, do których użytkownik ma dostęp) ze strony użytkownika nie przyjdzie żądanie z identyfikatorem obiektu, który nie był dostępny na tej liście. A to oczywiście jest błędne założenie.
Z reguły każdy z rekordów w bazie danych ma swój unikalny identyfikator. "Aż się prosi", by wykorzystać go jako identyfikator w aplikacji internetowej. Nie zawsze jest to dobre rozwiązanie, choć nie zawsze wykorzystanie takiego identyfikatora jest błędem. Jeśli dla przykładu identyfikator ten określa artykuł, przy czym z założenia wszystkie artykuły są dostępne dla każdego użytkownika, to zagrożenie ujawnienia danych w wyniku manipulacji tym identyfikatorem w tym wypadku nie istnieje - wszystkie informacje są jawne, więc o jakim ujawnieniu można tu mówić? Z drugiej strony, gdy w aplikacji jest wielu użytkowników, używanie takich globalnych identyfikatorów może spowodować i często powoduje błędy kontroli dostępu.
