Filtering in the UI is not security

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…

In this module: Module 11 · Security: who sees what

1. 1Where the trust boundary is
2. 2Filtering in the UI is not securityFree preview
3. 3Hiding a field sends it anyway
4. 4Filter at the source
5. 5Identity propagation, properly
6. 6Roles inside your application
7. 7Securing business object endpoints
8. 8Secrets do not go in an application
9. 9What ends up in a log or a URL
10. 10What breaks: four security findings
11. 11Lab briefing · Attack your own application