Authorization and Access Control

Authentication is a solved problem: there is one right answer, and Spring Security provides it. Authorization, on the other hand, is a design problem, and that is where the interesting vulnerabilities live. An attacker doesn't need to crack your BCrypt hash if they can view another customer's invoice by changing an identifier in the URL. OWASP places this type of flaw, broken access control, at the top of its risk ranking.

These flaws share one characteristic: they don't produce any error. An authorization rule that is too broad doesn't crash; it grants access. A rule placed behind another one that swallows it doesn't report anything; it is simply ignored. A @PreAuthorize annotation on a method called from within the same class doesn't apply; the call succeeds. In all three cases, the functional tests pass, the demo goes well, and access is wide open.

This lesson covers authorization at two levels. At the URL level, with authorizeHttpRequests, which protects the entrance to the building. At the method level, with @PreAuthorize, which protects each room, and which alone can answer the question "does this invoice really belong to the caller?", a question that a URL rule is structurally incapable of settling.