KWALIFIKACJA INF3 - TEST WIEDZY NR 3

PYTANIE NR 14.
Planujesz umieścić na swojej stronie internetowej film, który ma być dostępny tylko dla użytkowników z dostępem premium. Który z poniższych atrybutów HTML powinieneś użyć, aby zablokować dostęp do filmu dla użytkowników bez odpowiednich uprawnień?
A.
B.
C.
D.
Wyjaśnienie poprawnej odpowiedzi:
Żaden z podanych atrybutów nie służy do egzekwowania dostępu premium.
HTML opisuje strukturę i odtwarzanie, ale nie potrafi "zablokować" pliku dla nieuprawnionych. Ograniczenie dostępu realizuje się przez uwierzytelnianie i autoryzację po stronie serwera (np. sesja/token) oraz odpowiednie serwowanie zasobu.

Pełne wyjaśnienie:

W HTML nie istnieje standardowy atrybut, który skutecznie ogranicza dostęp do filmu tylko dla użytkowników premium. Atrybuty elementów multimedialnych (np. związane z odtwarzaniem, sterowaniem czy wstępnym ładowaniem) dotyczą sposobu prezentacji i zachowania odtwarzacza, a nie mechanizmów bezpieczeństwa.

Odpowiedź "Żaden z powyższych" jest poprawna, ponieważ nazwy typu "block", "restrict" czy "private" nie są atrybutami HTML używanymi do kontroli uprawnień. Nawet gdyby dodać własny atrybut (np. data-premium), przeglądarka nie wymusi na jego podstawie blokady pobrania pliku — użytkownik nadal mógłby wejść bezpośrednio na adres URL zasobu lub podejrzeć go w narzędziach deweloperskich.

Realna ochrona treści premium wymaga egzekwowania zasad po stronie serwera:

  • Uwierzytelnianie: ustalenie, kim jest użytkownik (np. sesja, token).
  • Autoryzacja: sprawdzenie, czy ma uprawnienie "premium".
  • Kontrola wydawania zasobu: serwowanie pliku/streamu tylko po pozytywnej weryfikacji.

Dlaczego pozostałe odpowiedzi są błędne? "block", "restrict", "private" mogą brzmieć intuicyjnie, ale nie są częścią standardu HTML w tym znaczeniu. To typowy "wabik" językowy: sugerują funkcję bezpieczeństwa, której HTML nie zapewnia. Na egzaminie warto pamiętać zasadę: zabezpieczenia muszą być wymuszane po stronie serwera, a frontend co najwyżej je odzwierciedla w interfejsie.

Dodatkowe pytania

Dodatkowe pytania (FAQ):
Autoryzacja to decyzja, czy użytkownik ma prawo do zasobu (np. filmu premium). HTML nie ma mechanizmu sprawdzania kont, ról ani blokowania pobrania pliku. To musi być egzekwowane przez serwer, który po weryfikacji sesji/tokena zwraca lub odmawia dostępu.
Atrybuty elementu wideo sterują odtwarzaniem i interfejsem (np. czy widać kontrolki, czy plik ma się wstępnie ładować, czy ma się zapętlać). Nie są przeznaczone do kontroli uprawnień. Dostęp premium realizuje się poza HTML, w logice serwera i aplikacji.
Przeglądarka ignoruje nieznane atrybuty albo traktuje je jako dane bez znaczenia dla bezpieczeństwa. Nawet jeśli dodasz taki atrybut w kodzie, użytkownik może skopiować adres pliku wideo i spróbować otworzyć go bezpośrednio. Bez blokady na serwerze nic nie jest faktycznie chronione.
Najczęściej robi się to tak, że plik jest wydawany przez endpoint serwera, który sprawdza zalogowanie i rolę "premium", a dopiero potem zwraca strumień. Alternatywnie stosuje się podpisane adresy URL z krótkim czasem ważności, aby utrudnić udostępnianie linków dalej.
Nie. Ukrycie elementu (np. przez CSS) zmienia tylko to, co widać na stronie, ale nie usuwa dostępu do pliku. Użytkownik może znaleźć URL zasobu w narzędziach deweloperskich lub w logach sieciowych. Zabezpieczenie musi polegać na odmowie odpowiedzi przez serwer.
Częsty błąd to wybór "brzmiącego" atrybutu zamiast odpowiedzi wskazującej na brak mechanizmu w HTML. Inny błąd to mylenie uwierzytelniania (logowanie) z autoryzacją (uprawnienia). Warto też pamiętać, że frontend nie może być jedyną linią obrony.
Broken Access Control to sytuacja, gdy aplikacja nie wymusza poprawnie uprawnień do zasobów. W kontekście filmów premium oznacza to, że ktoś bez premium może wejść na URL filmu i go pobrać/odtworzyć. Rozwiązaniem jest weryfikacja uprawnień na serwerze przy każdym żądaniu.
Sam token bez kontroli i ograniczeń może zostać skopiowany i udostępniony. Bezpieczniejsze są tokeny krótkotrwałe, podpisywane (signed URL) oraz powiązane z dodatkowymi warunkami (czas, IP, sesja). Kluczowe jest, aby serwer weryfikował token i odmawiał dostępu, gdy jest niepoprawny.
Sesja (np. cookie + stan na serwerze) bywa prostsza w tradycyjnych aplikacjach i ułatwia unieważnianie dostępu. JWT często stosuje się w architekturach API i SPA, gdy potrzebny jest token przenoszący dane o uprawnieniach. W obu przypadkach serwer musi weryfikować uprawnienia przed wydaniem filmu.
Jeśli pytanie dotyczy egzekwowania uprawnień (premium, role, dostęp tylko dla wybranych), a odpowiedzi są nazwami rzekomych atrybutów, to sygnał, że chodzi o rozdzielenie ról: HTML nie zabezpiecza zasobów. Wtedy poprawna bywa opcja mówiąca, że żaden atrybut nie rozwiązuje problemu.
info

Około 40% zdających odpowiada poprawnie na to pytanie. trudne

W praktyce zawodowej kluczowe jest to, że żaden z podanych atrybutów nie służy do egzekwowania dostępu premium.HTML opisuje strukturę i odtwarzanie, ale nie potrafi "zablokować" pliku dla nieuprawnionych.

Źródła:

  • WHATWG HTML Living Standard – sekcja dotycząca elementu video i jego atrybutów: https://html.spec.whatwg.org/multipage/media.html#the-video-element (dostęp: 2026-02-27)
  • MDN Web Docs – "<video>: The Video Embed element" (lista atrybutów i zachowań): https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video (dostęp: 2026-02-27)
  • OWASP Top 10 (2021) – A01:2021 Broken Access Control (opis problemu i praktyk): https://owasp.org/Top10/A01_2021-Broken_Access_Control/ (dostęp: 2026-02-27)

Materiały:

  • Dokumentacja HTML (element wideo i jego atrybuty) – specyfikacja WHATWG oraz omówienia na MDN
  • Materiały OWASP dotyczące kontroli dostępu (Broken Access Control)
  • Kursy/lekcje o uwierzytelnianiu i autoryzacji w aplikacjach webowych (sesje, JWT, role użytkowników)

Aktualizacja pytania: 31.03.2026



Aktualizacja pytania: 31.03.2026
📡 Brak połączenia internetowego