Security review · Assessment
Who can read other users’ data in your app?
We read your code to show who can reach what, before a customer’s security review asks. In our own design system, 188 findings came down to three causes.
FormatWritten assessment
TimelineDate agreed up front
PricingFixed-price assessment · hourly work
Proof3 case studies
The assessment in 4 parts
01 · Signs you need it
If two of these apply, this is a good fit.
- Nobody has checked who can read someone else’s data
- Permissions are enforced in the interface, and you aren’t sure the API checks them again
- A customer’s security review is coming, and you don’t know what they will ask
- Access rules grew one condition at a time, and nobody can say what a role can do without reading the whole codebase
02 · What you get
The document covers your access rules in four parts:
- A table of every user type and role against every action, so you can see who can reach what without reading code.
- Every place where a permission is checked only in the interface and the API accepts the request anyway.
- The causes behind the findings, since fixing a cause also prevents the findings it would have produced next.
- For each cause, whether an automated check in the build can catch it or someone has to keep looking for it by hand.
03 · How we decide
STEP 01The check has to be on the server.A check that runs only in the browser does nothing against someone who calls the API directly, so we confirm that the API enforces every rule on its own.
STEP 02We follow the whole chain of access.When access depends on a chain, such as a meeting, the document attached to it and that document’s versions, we check each link as well as the user’s role.
STEP 03Findings are grouped by cause.On our own design system, 188 findings came down to three causes, and every one of them had passed typecheck, ESLint and the build.
STEP 04Extensions, tokens and signed URLs get the least access that works.We compare what each one is allowed to do with what it actually uses. A signed URL works for anyone who has it, so we treat it like a credential.
04 · If we find nothing
You still get the table of roles and actions, and a written explanation of where your access rules hold and why. The next time a customer’s security review asks, the answer is already on paper.
Proof
Where we’ve done this before
Case study 04 · MarketplaceZero outagesA marketplace that had SQL injection reaching production when we took it over. In the first two months, before anything was rewritten, we added a firewall and closed the inherited security holes.Read the case study →Case study 08 · Marketplace506 routesFive kinds of user, from service vendors to a call center, share one codebase. Each type has its own routes. Permissions combine type and role, and the API validates them itself instead of trusting the route a request came from.Read the case study →Case study 15 · Business systemsSoldOn a remote-meeting platform sold into healthcare and finance, file access follows a graph of people, meetings and documents, and the browser extension requests a single permission, without media access.Read the case study →
FAQ
Questions about this service
No. We read the code and the access rules. A penetration test attacks the running system, and that is a separate job.
We need read access to the repositories, plus a description of your user types and roles. We work from the code, so we don’t touch production data.
Yes, as separate hourly work once the document shows what needs fixing.
Next step
Describe the problem and we’ll come back with three options.
The first call takes 30 minutes, and you’re under no obligation.