Sprawdzaj dostęp do konkretnych danych
Klient poprawnie się loguje i otwiera fakturę. Logowanie pozwala aplikacji zweryfikować konto użytkownika. Osobno trzeba ustalić, czy ta osoba ma prawo odczytać właśnie tę fakturę. To samo dotyczy zmiany zamówienia, pobrania dokumentu czy eksportu raportu.
Rozważmy hipotetyczny portal klienta. Użytkownik próbuje pobrać fakturę należącą do innej firmy, a aplikacja ją udostępnia. Konto jest prawidłowe, ale dostęp do tej faktury nie jest dozwolony. OWASP opisuje tę kategorię błędów w interfejsach API jako nieprawidłową kontrolę uprawnień na poziomie obiektu. Skutkiem może być ujawnienie lub zmiana informacji innego klienta.
Jasno określ zasady dostępu
Zacząłbym od krótkiej tabeli uprawnień: rola użytkownika, konto klienta, konkretne dane i żądana czynność. Odczyt faktury, zmiana danych płatniczych i zatwierdzenie zwrotu wymagają osobnej oceny. Sama nazwa roli „administrator” mówi zbyt mało, jeśli nie określono zakresu jej uprawnień.
Zapisz uzasadnione wyjątki, także dla pracowników wsparcia obsługujących różne konta klientów. Określ ich uprawnienia oraz ograniczenia. Chodzi o egzekwowanie uzgodnionej reguły biznesowej wszędzie, gdzie aplikacja udostępnia dane. Ukrycie przycisku lub zastosowanie trudnego do odgadnięcia identyfikatora dokumentu nie zastępuje tej kontroli.
Prześledź wszystkie sposoby dostępu do dokumentu
Serwer musi sprawdzić uprawnienia do konkretnych danych i żądanej czynności. Przejrzyj wszystkie miejsca, w których aplikacja udostępnia lub zmienia dane, w tym bezpośrednie pobieranie plików i zbiorcze eksporty. Zabezpieczenie jednego ekranu nie dowodzi, że wszędzie obowiązuje ta sama reguła.
W przypadku raportu przygotowywanego w tle sprawdziłbym, z czyich uprawnień korzysta zadanie, dane których klientów obejmuje oraz kto może pobrać gotowy plik. Szeroki dostęp techniczny takiego zadania nie powinien dawać osobie zamawiającej raport prawa do otrzymania wszystkich danych.
Testuj również przypadki, które trzeba odrzucić
Korzystaj z uzgodnionego środowiska testowego, sztucznych danych i osobnych kont klientów. Potwierdź, że każdy użytkownik może wykonywać przewidziane czynności na swoich danych. Następnie sprawdź te same czynności na istniejących danych poza jego zakresem uprawnień. Dzięki temu test dotyczy dostępu do rzeczywistych danych testowych, a nie próby otwarcia nieistniejącego dokumentu.
Sprawdź faktyczny wynik, nie tylko komunikat odpowiedzi: aplikacja nie powinna zwrócić zastrzeżonych danych ani wykonać niedozwolonej zmiany. Uwzględnij pobieranie plików i eksporty. Sprawdź też zachowanie po odebraniu dostępu lub zmianie roli. Zachowaj dozwolone i niedozwolone przypadki w testach regresji, przyjmując udokumentowaną tabelę uprawnień za podstawę oczekiwanych wyników.
Ustal, kto odpowiada za regułę
Osoby odpowiedzialne za dany obszar biznesowy powinny określić, kto może wykonywać każdą wrażliwą czynność. Zespół techniczny powinien wskazać, gdzie aplikacja egzekwuje tę decyzję, a osoby odpowiedzialne za bezpieczeństwo i testy — ją zweryfikować. Podczas przeglądu technicznego poprosiłbym o jeden przykład łączący regułę biznesową, kontrolę po stronie serwera i wynik testu.
Zacznij od jednego procesu wymagającego ochrony, na przykład udostępniania dokumentów lub zwrotu płatności. Prześledź wszystkie sposoby dostępu, zanim rozszerzysz przegląd. To daje zespołowi konkretny sposób sprawdzania, czy aplikacja zachowuje granice dostępu między klientami także po kolejnych zmianach.