Home / Authorization
The flagship
Every role. Every door. Every time.
When a breach ends a company it is rarely an exotic piece of hacking. It is one customer's login reading another customer's data. That is the hardest thing in security to test automatically, and it is the reason we ask you for more than one login.
The output
One grid, read in five seconds
| role \ resource | GET /invoices/:id | POST /refunds | GET /users/:id/pii | PATCH /orgs/:id/plan | DELETE /audit-log |
|---|---|---|---|---|---|
| Viewer | |||||
| Support | |||||
| Manager | |||||
| Admin |
Why your scanner cannot do it
It only ever had one login
This is not a gap a vendor can close with more patterns. It follows from how the tool is built.
One login, so nothing to compare
A scanner signs in once and looks around. Testing whether the support account can reach the finance account's records needs both accounts, at the same time, in the same run. With one login there is no second answer to compare against, so the question is never asked.
It has never been a partner
Your roles mean something in your business. A partner, a support agent, a finance approver, a trial account: each one is allowed a different set of things, and that list exists in your code and in your head. A tool that has never held those accounts cannot know that a partner should not be able to read your invoices.
And this is the one that ends companies
One customer seeing another customer's data is the incident that becomes a regulator's letter, an email to every account and a story with your name in it. It is also silent: nothing crashed, nothing was logged as an error, and every request came back as a success.
How we do it
The rule and the reality, side by side
Who is allowed to do what is a decision written into your code and carried out by your server. Checking it means comparing the two. Almost every tool can only see one of them.
Your code states the rule
Somewhere in the repository is the line that decides whether this person may see this record. We read it, so we know what the answer is supposed to be before we ask the question.
Your server gives the answer
What the code intends and what the running system does are not always the same thing, once middleware, a gateway and a database sit in between. Only a real request settles it.
We hold every key
Give us one login per role. We try every role against every resource and write down what the server actually did. Every square in that grid is a request that was genuinely sent.
What it catches
The findings that reach the board pack
One customer reading another
An account of the same rank reading, editing or deleting records that belong to a different customer. Found by actually trying it as the wrong customer, not by guessing.
A junior role doing a senior job
A support agent reaching an admin action. A read-only account writing. A trial account using something only paying customers should have.
Logged in, but never checked
An endpoint that confirms you are someone and forgets to confirm you are the right someone. The single most common version of this we see.
Trusting the form, not the session
Ownership decided from a value the caller sent rather than from who they signed in as. So the caller simply types in somebody else's identifier.
Doors nobody remembers
Internal, legacy and debug endpoints still reachable in production, with no rule attached to them at all because nobody remembered they were there.
Erasing the evidence
Roles that can quietly delete the record of what they did. That turns an incident you can explain into one you cannot.
Setting it up
Three things we need from you
A login for each role
Stored encrypted, or pulled from your own Azure Key Vault when a scan starts. Tell us what each one is called and how senior it is meant to be.
The repository
So we can read what each door is supposed to enforce, instead of working it out from the outside. It never has to leave your network. Private scanning →
The rules of engagement
Anything destructive we should not attempt, and any account we should leave alone. We never test anything you have not signed off.
The same result, drawn
The two paths that should not exist.
Every role joined to every resource it can actually reach. The allowed paths are in mint. The two in coral worked with a valid login and should not have.
Run it against your own roles.
Give us the roles your application has, plus the handful of things you would least like the wrong one to reach. We will show you the grid filled in, and what a pink square looks like when it is somebody else’s data.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.