A table filtered to ONE DEPARTMENT has ALREADY RECEIVED THE OTHERS. Open the network tab and READ WHAT WAS ACTUALLY RETURNED.
This is the most common security defect in applications built this way, and it is committed by people doing something that looks entirely reasonable.
THE PATTERN IS: FETCH THE LIST, FILTER IT IN THE BROWSER, BIND THE FILTERED RESULT TO THE TABLE. It is simple, it is fast to write, and Module 7 Lesson 7 already noted it as a performance decision. Here it is the same code with a different consequence: the rows you filtered out were delivered to the user before you removed them.
THE PAGE IS CORRECT. The user sees only their department and there is no way, using the application, to see more. And the data for every other department is in the response, in the browser, in memory, one tab away.
WHICH MEANS THE PROTECTION IS THE PAGE CHOOSING NOT TO SHOW SOMETHING IT WAS GIVEN. That is not a control — a control is not being given it.
THE REASON IT SURVIVES REVIEW IS THAT EVERY SCREEN SHOWS THE RIGHT THING. Nobody looking at the application can see the problem, and it will not appear in any test that drives the UI. It is visible only in the response, which is why this lesson's instruction is literally to open the tab and read what came back.
AND IT IS WORSE THAN IT LOOKS, BECAUSE THE ROWS FILTERED OUT ARE USUALLY THE SENSITIVE ONES. Filtering by department, by region, by owner — the filter exists precisely because the other rows are not for this person, so what leaks is exactly what was meant to be restricted.
THE FIX IS LESSON 4: THE SERVICE RETURNS ONLY THEIR ROWS. Which usually means a query parameter and sometimes means Lesson 5's identity propagation. Keep the browser-side filter if it helps the interface — a search box, a quick narrowing — but only over data the user was entitled to receive.