Skip to content

API Security Report & Actions

API Security › API Security Report & Actions scans the account and tells you where a person could read or change data which is not theirs, then lets you fix it from the same page.

Two gates, one report

Every request carries two identities, and the report checks both :

Gate Header Question What the report checks
API gate x-am-authorization May this application call this API ? Groups with broad flags (allInstances, allCollections, allSystemApis ...), sensitive system APIs, bulk update / delete grants, unused groups
Row gate x-am-user-authorization, x-aws-authorization, x-google-authorization, x-azure-authorization, x-custom-authorization Of the rows this API reaches, which ones belong to this person ? For every collection the groups reach : whether an active pre-hook reads the person (g.req.auth.authAMDB ...) and limits every family of APIs (query.find for get-all and the *-by-id APIs, body.find for query, count, update-many, remove-by-query ...) to their rows, merges with $and, stamps the owner on writes and refuses aggregate / distinct

The row gate is the point of the feature. The generated APIs are powerful : with find, deep, find-join, query, update-many and remove-by-query a caller who is allowed on a collection reaches every row of it unless a pre-hook narrows the request. The report reads the code of your pre-hooks (instance, database, collection and API level) and decides, per collection and per API, whether that narrowing happens.

It also reviews the auth providers (password in the token, unhashed passwords, no groups column, long lived tokens), public APIs (instance APIs and custom APIs with IS_PUBLIC) and a platform switch it can turn on for you :

  • Block inline SQL in find : values and keys which json-sql-builder2 would paste into the statement as-is (__: prefix, __ helper) are bound as plain parameters on the SQL instances, so they match nothing instead of rewriting the statement.

deep and find-join need no switch : the rows of the related collection are read through its own query API, with the group check of the caller, and only for the keys of the rows the caller could see.

The score

Every open finding takes points off 100 (critical 20, high 10, medium 4, low 1). Skipped and fixed findings take nothing. The grade (A to F) and the trend over the last scans are shown on the page and printed in the report.

Actions

Each finding offers what fixes it : an action when the fix can be automated, otherwise a link to the page where the change is made. Nothing is changed behind your back : an action runs when you click it, goes through the same routes as the admin panel (validation, TypeScript compile, git sync), and the account is scanned again right after so the report shows the result.

Action What it does
Add a row scoping pre-hook Installs a collection (or database) level pre-hook which merges { ownerColumn: personId } into query.find / body.find with $and, stamps the owner on every write and refuses aggregate / distinct. You pick the owner column and the field of the token, can limit the hook to some groups of API users (the groups which reach the collection are listed first, with their API users), and can edit the code before it is saved.
Add "column" to the token of a provider Puts a column of the users table into the select of a DB token generator, so the token carries it and the hook can compare it. Persons log in again to get the new token.
Require a person token on this collection Writes collection settings naming the auth providers, so every API of the collection needs a person token next to the API user token.
Activate the hook Switches an inactive row scoping hook back on.
Freeze to an explicit allow-list / turn the flag off Narrows a broad group flag. Freeze writes what the group reaches today as explicit grants first, so nothing added later is reachable through it.
Revoke grants Takes sensitive system APIs or bulk APIs away from a group.
Block inline SQL in find The platform switch above.
Skip Marks a finding as acceptable, with a reason. It leaves the score, and the reason is kept in git.

A finding which suggests code shows it in a read only editor, and links such as "Open the collection" or "Open the group" open the page of the target in a new tab, so the report stays where it is.

Automatic scans

While a local client is connected to the account, API Maker scans it on its own and keeps the report fresh, on the disk of the developer and in git, so an AI assistant working in the folder of the project always reads the current report.

  • The pace follows the account. The next scan comes 100 times the duration of the last one later, never closer than 1 minute and never further than 30 minutes : a scan which takes 300 ms runs every minute, one which takes 20 s runs every 30 minutes.
  • Nothing runs when nothing changed. Between two scans, only a fingerprint of the inputs is read (one count and one date per collection of API Maker : groups, API users, auth providers, hooks, settings, schemas, instances, custom APIs, the secrets and the admin user). When it is the one of the last scan, no scan runs. With the live catalog on, a scan still runs every 30 minutes, for the tables added to a live database.
  • Nothing is saved when the report did not change. A scan which finds the same findings saves nothing, so the local client and git see nothing. A scan which finds a different report saves it, sends the folder to the local client and, when the account has a git repository, commits the folder src/API Security Report/ alone (what you have not committed yet stays as it is), at most once every 5 minutes.
  • Never in the way. A scan runs in the process which holds the connection, one at a time per account, and waits when the server is busy answering requests.

The panel Automatic scans of the page shows whether a local client is connected, what the last cycle did, when the next one is due at the earliest, and the last commit. Two switches, saved with the report, turn the automatic scans and the automatic commits off ; the play button runs one cycle right away.

In the repository

The report is committed with the rest of the project as the folder src/API Security Report/ :

File Content
README.md What the folder is, for people and AI assistants : read only, work on the findings, rescan
report.md The full report : summary, scope, every finding with its evidence, the request which exploits it, what to do and the suggested code
report.yaml The same, machine readable
actions.yaml The skipped findings with their reasons, and the log of the actions taken from the page

API Maker only ever writes these files. The one thing it reads back is the skipped section of actions.yaml, on a git pull, so the decisions of the team follow the project. An AI assistant working on the repository can read report.md, fix the hooks, groups, settings and providers in their own folders, commit, and the automatic scan (or you, from the admin panel) rescans.

Printing

The download menu of the page prints the report (A4, with or without the skipped findings) through the print dialog of the browser, where "Save as PDF" makes the file, and downloads report.md, report.yaml or report.json.