Skip to content
This page View Markdown Open in ChatGPT Open in Claude

Security overview

Every API of API Maker is locked until you open it, and two gates decide who reaches what : groups decide which APIs, a pre hook decides which rows. The security report reads your settings and your code, and says where the second gate is missing.

Locked by default

Part How it is locked
Database and custom APIs A call needs the token of an API user whose groups grant that API. Only the APIs you mark IS_PUBLIC in their settings skip it.
System APIs Closed over HTTP : your code calls them, an HTTP call answers 401 until a system API setting opens it. The token API is the exception.
Fields A group grants read and write per field : a field it does not grant is absent from the answer.
Secrets Keys and connection strings live in the secret, encrypted on the server and never in Git. Each account gets keys of its own.

A new account starts open for its first steps : an API user default with the password 12345, and a group Default which grants everything. Replace both before real data arrives : see Before you go live.

Two gates

The API gate and the row gate

  • The API gate : who may call which API. The application sends the token of its API user (x-am-authorization) ; its groups grant APIs, tables and fields. A person sends a token of their own (x-am-user-authorization), made by an auth provider ; their groups must grant the API too.
  • The row gate : which rows that person reaches. Groups can not know that order 1042 belongs to Ada : that is a fact of the data. A pre hook adds the owner to every filter and stamps it on every write. The security report installs it in one click.
The row gate : the same call, without and with the row scoping pre hook without the hook GET …/sales/orders Diya signed in : customer_id 2 every order 1001 · Diya 1002 · Kabir 1003 · Diya 1004 · Kabir and every other customer with the row scoping pre hook the hook adds the owner find = { $and: [   what Diya sent,   { customer_id: 2 } ] } her orders 1001 · Diya 1003 · Diya Nothing Diya sends can widen it : $and keeps her filter and adds the owner. Writes get the owner stamped ; aggregate and distinct are refused. Groups decide which APIs the app may call. Only the hook knows which rows are Diya's.

Handle role based permissions builds both gates step by step, and tries to break them.

What is checked where

Question Answered by Page
Is the caller an application we know ? The token of an API user API users
Which person is it ? The token of an auth provider Auth providers
May they call this API, read this field ? Groups Groups
Is this row theirs ? A pre hook Pre hooks
Is this data valid ? The schema of the table Schema
Where is a leak ? The security report Security report
From which web sites ? Allowed origins Security features

The sandboxes : what they protect, and what they do not

The code of an account (custom APIs, hooks, schedulers, events) runs in Docker containers of that account, apart from the process of API Maker, with a time limit. They keep API Maker running when code fails : an exception ends its request with an error, and code which runs too long is cut short while a new runner takes the next requests.

Where code runs : sandboxes per account and language, and the native process API Maker one process per server, every core ; settings and schemas run here a run past its time is cut short, an error ends it sandboxes : Docker containers of each account account shop · TypeScript 1 sandbox, more while busy, up to the count account shop · Python its own runtime, packages and Dockerfile account crm · Go native process · runOnNativeProcess on the machine, beside API Maker : not isolated The trust model Containers run privileged, with no memory limit : a guard against faulty code, not hostile code. Separate clients : separate servers. Like the sandboxes, the native runner answers what the code asks of g.sys itself, and hands only the answer back.

They are not a wall against hostile code :

  • The containers run privileged. Code which wants to can reach the server around them, and from there the secrets of every account of the server.
  • They have no memory limit. A leak takes memory of the whole server.
  • The native process is not isolated at all. Code with runOnNativeProcess: true runs on the machine of the server, beside API Maker.

So run on one server only code you trust : your team's, or an AI's that your team reviewed. For clients who must not see each other's data, use separate servers, not separate accounts of one server.

What API Maker sends to us

API Maker has no analytics. A server checks its licence key with the licence server of API Maker (sava.be.apimaker.dev), and sends nothing else :
What it sends The licence key, the MAC addresses of the machine and its number of CPU cores.
When A minute or two after it starts, every day at about 12:00 (time of India), every four hours while a check gets no answer, and when a key is written.
What it never sends Data of your databases, your APIs, logs, code or users.
What a failed check does Nothing to your APIs : the licence page of the admin panel shows the problem. A licence server which does not answer changes nothing.
The key of API Maker Launchpad Never sent : the licence page shows LOCAL.

Before you go live

The checklist : default passwords, the default group, the row gate, public APIs, HTTPS, backups.

Report a vulnerability

Write to [email protected] with the steps to reproduce it. Please give us time to fix it before you publish.