A lock that keeps everyone out is also broken
Testing that a stranger cannot read another kitchen's takings is half the test. The half people skip is checking the person who should get in still does.
In a food hall every kitchen is a different business, and the most important promise the software makes is the dullest one: your numbers are yours. Nobody else's screen shows your takings, your suppliers, your margins.
The way you check that promise is to try to break it. Sign in as one kitchen, ask for another kitchen's data, and confirm you are refused. We do that, and we write the attempt down as a test so it runs forever.
But an attack test on its own can pass for a humiliating reason.
The failure that looks like success
Suppose a change accidentally breaks the screen so badly that everyone is refused — including the person the data belongs to. The attack test still passes. It asked "is the intruder refused?" and the answer is still yes.
Meanwhile the kitchen that owns the numbers opens its dashboard and sees nothing, and the test suite is entirely happy about it.
So every refusal we check is paired with the same request made by somebody who is entitled to make it, and that one has to succeed. Two halves of one fact: the door is locked, and the key works.
The other thing worth knowing
There is a second way to test a fence wrongly, and it is subtler. You can call the code that handles the request directly, skipping everything the request would normally pass through on the way in.
That answers the question "does this piece of code check?" — which is not the question. The question is "does this request get through?" We found this out the expensive way: a check done that way reported a wide-open hole in something that turned out to be properly fenced, because the fence sits in the path the fake test had skipped. Had we believed it, we would have "fixed" a route that was fine and written a real defence down as absent.
Attack the thing the way the internet attacks it — through the front door, with a real request — or you are testing a diagram of your software rather than your software.
What to ask a supplier
Not "is it secure". Ask: have you tried, as one of my vendors, to read another vendor's sales — and do you re-run that attempt automatically on every release? Then ask the second half: and does the same test prove the right vendor still gets their own?