Who can see what: the test your scanner cannot run.

The whole test is one table

An authorization matrix is not a new category of security product. It is a table. Your user types run down the side. The things your application can do run across the top: a page, an API call, a record, an action that moves money. Every square in the middle is one real request, sent while signed in as that user type, aimed at that resource, and written down as one of three answers.

Allowed, and meant to be. Denied, and meant to be. Or got in, and should not have. Green means the door is locked the way you meant. Pink means somebody reached something that was never theirs. You can read your whole permission model in about five seconds, which is unusual for anything in this industry.

What makes it hard is not the table. It is filling it in: every square is an account you have to hold and a request you have to send for real.

Five people who are not the same person

We ask for one working login per role. In most products the shape is roughly this, and the names change more than the problem does. Five roles against five resources is twenty-five requests, and a real application has hundreds of doors.

Why one login cannot produce this

This is worth being precise about. It is not a criticism of anyone's engineering, it follows from how a scanner is built.

A scanner signs in once and looks around. Testing whether the support account can reach the finance account's records requires both accounts, live, in the same run, so the two answers can be compared. With one login there is no second answer, so the comparison never happens and the question is never asked. The tool is not failing the test. It cannot sit the test.

There is a second, deeper reason. Your roles mean something in your business, and that meaning lives in your code and in your team's heads. A tool that has never held those accounts cannot know that a partner should not be able to read your invoices, because nothing in the traffic says so, and nothing in a signature file says it either. A 200 looks like success. It only becomes a breach when you know who asked.

So when a scanner reports nothing in this class, that is not a clean bill of health. It is silence from a tool that was never asking. Keep the scanner. This is the part it cannot see.

What one pink square actually costs

This is the finding that reaches the board pack. One customer reading another customer's data is the incident that becomes a regulator's letter, an email to every account you have, and a story with your name in the headline. Companies do not usually die of an exotic piece of hacking. They die of a support agent, or a partner, or a stranger, reading a record that belonged to someone else.

The worst property of this class of bug is that it is silent. Nothing crashed, nothing was logged as an error, and every request came back as a success, because from the server's point of view a valid session asked a valid question and got a valid answer. Your monitoring will not raise it and your logs will not show a single refused request. You find out when somebody else finds out.

How we fill the table in

You give us one credential per role, stored encrypted or pulled from your own Azure Key Vault when a scan starts, and you tell us what each role is meant to do. We read your repository, so we know which line of code makes each decision and what answer it is meant to give. Then we send the requests.

That pairing is the whole method: the code states the rule, the running application gives the verdict, and the interesting bugs live in the gap between the two, where a gateway, a piece of middleware or an ownership check reading the wrong field turned a clear intention into a different behaviour.

Anything pink becomes a finding with the proof attached: the request we sent and which role was signed in, the response that came back and what should have come back instead, a screenshot of the result, and the file and line that let it through. If we did not break it, we do not report it. The matrix is live today.

What it does not do

Four honest limits. Finding these in week three of a pilot is worse for both of us.

It needs the accounts. One login gets you one row. If a credential has expired, or a role can only be created by an internal process we cannot run, that row is missing and the report says so rather than quietly leaving a gap.

It tests the rule, not your intent. We can prove that a rule was not enforced. Whether the rule itself is the right one for your business is your call, which is why we ask what each role is for before the first scan.

It covers web applications and their APIs. Not networks, not infrastructure. A door that is not reachable from the application or visible in the code we read is not in the table.

It is not the business-logic module. Reaching a resource you should not reach is authorization. Abusing the rules of the product once you are allowed in, stacked discounts, negative quantities, a quota that resets on a downgrade, is a different test. It lands 4 January.

We have not published a detection rate for any of this and we are not going to invent one. The benchmark, misses included, publishes 3 November. The full list of what we have not proved →