Security and auth products

You have been told your product is secure.

There is no artefact you can look at to check that. A permission model lives in half a dozen places at once, and none of them prints a report anybody can hand over.

So here is the failure it usually hides.

Most access control is correct in the interface and missing from the database. The button is hidden. The route redirects.

The menu does not render for anybody without the role, and every one of those is a drawing decision rather than a boundary.

The boundary is the query. The query is still there when somebody opens the network tab.

It is rarely found by testing, because the person testing is signed in as an administrator and an administrator passes every check that was supposed to fail.

So the boundary is on the server and the client only decides what to draw.

That is the whole design. Everything else follows from it.

Without a server that must be kept alive, the boundary lives in the database's own rules — row-level security in Postgres, security rules in Firestore — rather than in a middleware layer somebody has to pay to keep running.

That has a consequence worth knowing before you buy it. Row-level security filters rather than refuses, so a read somebody should not be allowed to make returns an empty list with a 200, and a forbidden update reports success with zero rows changed.

A test that checks only the status code passes. The probe has to check what came back.

The second consequence is the useful one. A boundary written into the database applies to every path that reaches the data, including one somebody adds next year without reading this page.

What an engagement of this shape covers does not move from project to project.

Social and passwordless sign-in. Biometric unlock on native. Two-factor and recovery flows.

A role and permission model read at query time rather than at render time. And the non-admin probe that proves the gate holds.

That probe is what makes the rest of it checkable. It runs as an ordinary user, with a second user's data already in the database, because a gate tested by the account that bypasses it has not been tested. That is one seeded account, and it is the only step here that produces evidence.

Two-factor is where most of the detail hides. The second factor is easy; the recovery code, the rate limit on the verify step and the audit row saying who turned it off are where the work actually goes.

Passwordless deserves its own sentence. A sign-in link or a passkey takes the password out of the threat model entirely, and what replaces it is a recovery path that has to be written at least as carefully.

2FA Studio, Capacitor Biometric Authentication, WebAuthn Server BuildKit and Capacitor Auth Manager all sit in this area, and each has its own page on this site. OAuth, WebAuthn and row-level security are the default set.

The costs are specific and none of them is optional. Recovery is more work than sign-in.

Signing in is one screen; losing a device, losing a phone number and losing an authenticator are three flows, each with its own way of being abused, and each has to exist before the feature is honestly finished.

A permission model read at query time means every list query carries the filter its rule depends on, so adding a screen means adding a filter rather than adding a check.

The probe costs a second account and real data in the database. That is slower than reading the rules, and it is the only thing that proves them.

There is one more cost you may not expect. Some of the requests that arrive after launch are requests to weaken the model, and those get talked through before anything is changed.

A green build is not evidence that a feature works. It is especially not evidence here, because this failure looks exactly like success from the outside.

The exclusions are the catalogue's rather than this page's. Visual design as a standalone deliverable. Native iOS, so biometric unlock means Android and the platform APIs the web offers, and nothing on an iPhone. Blockchain work. Copywriting and content.

There is also a claim I will not make. No design makes a system secure, and a page that says otherwise is making a promise nobody can keep.

My name is Ahsan Mahmood, and what I can do is put the boundary somewhere a probe can reach it and then run that probe in front of you.

Thirty days of bug fixes at no charge, and after that nothing is automatic.

The parts that stay your responsibility get named on the call rather than found in an incident.