Security Testing

A security configuration has an unpleasant property: it fails silently in the direction that matters. If a rule is too strict, you find out within thirty seconds, because someone complains that they can't access a page. If it is too permissive, nobody complains. Ever. The application works, everyone can reach what they want, and the flaw is discovered by an audit, or by someone with less benign intentions.

Security tests correct this asymmetry, and they have one distinctive trait: the interesting cases are the negative ones. A test that checks that an administrator can reach the admin console has little value; that path is exercised constantly. The test that matters is the one that verifies that an ordinary user gets a 403, that an anonymous user gets a 401, and that a customer cannot read another customer's invoice.

These tests have a second virtue: they document your permissions model in executable form. When someone adds a rule in six months and accidentally shadows a more specific one, it is the negative test that will stop them, not code review.

This lesson shows how to write these tests with spring-security-test. It focuses on two configurations that produce green but empty tests and give a false sense of assurance: forgetting to import your own security configuration, and disabling the filters.