APIs Security Report: Find Data Leaks and Fix Them in One Click

Security reviews come too late

0:00 API Maker reads your whole account and tells you where a person could reach data that is not theirs. Then it fixes it, one click at a time. Security reviews are usually manual, late and rare : a spreadsheet before a release, when somebody has the time. Meanwhile, one application token reads every row of a table, a wildcard grant reaches the tables added next year, and a hook that looks right filters one API out of four.

0:28 Backends written fast, by people or by AI assistants, ship with these holes. API Maker scans the account on every change, shows the proof, applies the fix through the same validated routes, and keeps every decision in git. In this video : a weak account, the scan and its score, how the scanner thinks, one finding in detail, the fixes, with the score rising, export and print, and automatic scans, kept in git for your AI assistants.

The weak account

0:58 Here is Calm Home after a busy sprint. The customer app got a login table in PostgreSQL with the auth provider app_login, and a group of its own. A back office tool got Execute plain query and Get secret keys. Countries went public. The support tickets hook was switched off while debugging. And the Default group, as in every new account, still reaches everything. Nothing here looks dangerous on its own.

1:24 Yet the token of the customer app reads all 180 orders of 59 customers.

Scan and score

1:31 In the Security panel, open APIs Security Report and Actions. Before the first scan, the page lists the six questions it asks : row gate, public access, code, API gate, auth providers and hygiene. For this demo, we keep the scan to what API Maker already knows, and scan the account. Zero out of a hundred, grade F : unprotected. Open findings, several of them critical, across six instances and twenty four collections.

2:02 Every open finding takes points off a hundred : twenty for a critical, ten for a high, four for a medium and one for a low. Below, where the risks are : one line per category, the clear ones ticked. A severity opens its findings, with the summary folded to one line, one click clears the filter, and the findings are grouped by category, the worst first.

How it thinks

2:25 Every request carries two identities, and the report checks both. The API gate is the API user token, in x-am-authorization : which APIs may this application call? The row gate is the token of the person, in x-am-user-authorization : of the rows this API reaches, which ones belong to this person? The row gate is the heart of the report, because without a filter, a caller allowed on a table reaches every row of it.

2:55 A simple example. Diya and Kabir both shop with the customer app. Diya's phone asks for orders with two tokens : the app's, and hers. The API gate lets the app read orders, but nothing limits the rows : Diya changes one number in the request, customer five, and reads Kabir's order, its number and its total. With a row scoping hook, the same request answers nothing. Finding these tables before Diya does is the job of the report.

3:26 A scan is a pure function of a snapshot. It reads the groups, API users, auth providers, settings, secrets, schemas and pre-hooks. It works out which group reaches which API of which collection. It guesses the column that names the owner of a row : a relation to the users table, a column named after it, or a common name like user id. It parses every pre-hook, in any of the eight languages, without running it : it checks four families of APIs, and that each filter is built from the person.

4:00 Then dozens of rules write the findings, and more read the code itself. All of it is Rust, and the scan takes well under a second.

A finding

4:09 Open a finding, here orders, in MySQL. The head names the severity, the category, the target and a link to its page, and why it matters is said in plain words. Then the reachable APIs, grouped by what they read, change or delete, and the evidence : the groups that grant them, a person token, not required, and the owner column, customer_id, with how sure the report is : it is named after the users table of app_login.

4:37 How to fix it closes the pane, above the actions that apply the fix.

Fix it

4:43 Now, the fixes. Every action goes through the same routes as the admin panel, validation, TypeScript compile and git sync included, and the account is scanned again right after.

Fix: narrow a group

4:56 The first critical finding : Default reaches every instance, database, collection and API, including the tables added next month. The dialog offers two ways. Freeze writes what the group reaches today as explicit grants, then turns the flag off. Turn the flag off only keeps the explicit grants, and Default has none. The customer app has a group of its own, so Default does not need the data : apply and scan again.

5:24 Several findings close at once, and the three flags below it go the same way.

Fix: system APIs

5:30 Default also reaches every system API, Execute plain query and Get secret keys included. This flag cannot be frozen, so it goes off, and the score rises. The back office group names the two sensitive ones explicitly. Revoke these system APIs lists them as checkboxes, and the group keeps every other grant. Apply : higher again.

Fix: skip with a reason

5:53 Countries is public on purpose : the app shows it before anybody signs in. Skip asks why that is acceptable. The reason is kept with the report, and committed to git. The finding leaves the score, and it rises. The Skipped tab keeps it, with the reason, who skipped it and when. Open it again brings it back, with its twenty points. We skip it once more, and move on.

Fix: person token

6:19 Now the row gate. Orders belongs to persons, but its APIs need no person token. Require a person token writes the collection settings of orders, with app_login. Apply, and every API of orders needs a person next to the API user. The scan tells the next truth : a person is known, but nothing limits the rows to theirs. That is critical, and the score drops. The report counts risk, not effort.

Fix: row scoping hook

6:47 The evidence shows a gap : the token of app_login carries the email and the id, not customer_id. One click adds customer_id to the select of the provider. Then, add a row scoping pre-hook. On its Settings tab, the owner column and the identity in the token are picked for you, and the safe behaviour is on. The Code tab holds the generated hook : it can be edited before it is saved.

7:13 Apply, and the score climbs. The generated hook follows one standard. Internal calls of custom APIs and schedulers pass through. No person, no rows. The owner is merged with dollar and, never replaced, so a caller cannot widen the rows. Every write is stamped with the owner. And aggregate and distinct are refused : fail closed. Diya signs in to the customer app. With the token of the app and her own, orders now answers her two orders, and nothing else.

Fix: activate a hook

7:47 Support tickets has a hook, Only my tickets, switched off. The report has already read its code : it reads the person and filters get all, but not query. It stamps nothing, refuses nothing, and merges with an object spread. Activate it, and the score goes down. The hook is graded on what it does, not on its name or its comments. That is how a hook that looks right, written by a person or an AI assistant, gets caught.

8:15 The finding lists the APIs the hook leaves open. Replace with a hook covering every API installs the generated one, and the score climbs again.

Links to pages

8:26 Some fixes are yours to make, like a groups column for app_login. The link opens the page of the target in a new tab, so the report stays where it is.

The score

8:36 Here is the story in the trend of the score. Zero at the first scan. Up with every flag, grant and token. Down once, when the old hook of support tickets was switched on and graded, up again with the generated hooks, and grade A, once the last flags of Default went off.

Export and print

8:55 The report also leaves the page. The download menu prints it, with or without the skipped findings, and downloads report.md, report.yaml or report.json. Print, then Save as PDF in the dialog of the browser. Page one is the summary : the score, the severities, what to fix first and what was scanned. The findings follow, with their evidence and their fix. The Markdown has the same content, for a ticket or a pull request.

Automatic scans

9:26 While a local client is connected, the report keeps itself fresh. When a scan is due, one count and one date per model tell whether anything changed. Only a change starts a scan, only a different report is saved, and its folder is committed to git, at most every five minutes. The next scan is due a hundred times the length of the last one later, between one and thirty minutes.

Git and AI

9:50 In the repository, the report is a folder of four files : report.md, report.yaml, actions.yaml with every skip and its reason, and a README for people and AI assistants. Read only. Work on the findings, not on the report. Respect the skips. An assistant reads report.md, fixes the hook in its own file, and the next scan grades its work. API Maker reads one thing back : the skipped findings.

Best practices

10:20 Best practices. Keep the local client connected, so every change is scanned. No broad flag in a production group. A person token on every table that belongs to persons, with the generated hook. Skip only with a reason that holds. And keep the report in git, next to the code.

Recap

10:40 That was the APIs Security Report. One scan, one score. The proof behind every finding. Fixes in one click, through the routes of the panel. A PDF for the review, and the report in git for your AI assistants. Next, the other security features : encryption, secrets, origins and two step login. API Maker. Build faster, spend smarter, deliver better.