API Maker

The backend engine for the AI era

Security

Security Features

Encrypted payloads, allowed origins, two-factor sign-in and package audits, on top of tokens and groups.

Beyond who may call what, API Maker can require encrypted request bodies and return encrypted responses, refuse browsers from other origins, ask a second factor when people sign in to the admin panel, and check the packages of your sandboxes, in every language, for known vulnerabilities.

See it live

Step through it, slow it down, or open the full canvas.

api-maker/features/securityLive
  • Request
  • Allowed
  • Encrypted
  • Refused
Origins
2allowed
Refused
0requests
Replay window
300seconds
Encrypted
0in and out

Only the browsers of your apps. List the origins of your web apps. A browser request from any other origin gets 403 before anything runs. Calls without an Origin header, like servers, are not affected.

How it works

  1. Only the browsers of your apps.

    List the origins of your web apps. A browser request from any other origin gets 403 before anything runs. Calls without an Origin header, like servers, are not affected.

  2. Bodies stay unreadable on the way.

    The app encrypts { data, createdAt } with the transfer key of your secret and sends dataEncFE. Turn on acceptOnlyEncryptedData and plain bodies are refused.

  3. A captured request expires.

    The payload carries its creation time. Sent again after feTransferDataValidityInSeconds, 300 seconds here, it is refused: Payload expired.

  4. The answer can go back encrypted.

    x-am-get-encrypted-data asks for the answer in encryptedData, alone or next to data.

  5. Two-factor sign-in for the admin panel.

    The root user can require a code from an authenticator app, a code sent by email, or both. Recovery codes are shown once and stored hashed.

  6. Packages checked for known vulnerabilities.

    The vulnerabilities page audits the packages you add to your sandboxes, in every language, and the Rust crates API Maker is built from.

What you get

Encrypted request payloads

Turn on acceptOnlyEncryptedData for a database, a table, an API, a custom or system API, and plain bodies and query strings are refused.

Encrypted and hashed fields

Schema conversions store sensitive fields encrypted or as HMAC SHA-256 hashes, with the keys of your secret.

Two-factor sign-in

The root user can require a code from an authenticator app, a code sent by email, or both, when people sign in to the admin panel. Recovery codes are shown once and stored hashed.

An example

A proxy you do not control

A partner network ends TLS at its own proxy before the traffic reaches your server. The app encrypts each body with the transfer key, so the proxy only sees ciphertext, and a captured request can not be replayed after a few minutes. Admin users sign in with their authenticator app.

An encrypted requestrequest
POST /api/schema/admin/shop/main/orders/save-single-or-multiplex-am-authorization: <API user token>x-am-encrypted-payload: truex-am-get-encrypted-data: get_only_encryption{ "dataEncFE": "U2FsdGVkX1+q3n…" }

dataEncFE is { data, createdAt } encrypted with encryptionAlgorithmFETransfer and secretFETransfer of the secret, the key you share with your frontend or mobile app.

The transfer keys in the secretsecret.ts
common: <T.ISecretTypeCommon>{    encryptionAlgorithmFETransfer: 'AES',    secretFETransfer: '…',    feTransferDataValidityInSeconds: 300, // older payloads are refused},

Watch it

On the real admin panel, with real data.

Good to know

  • The transfer key is shared with your frontend or mobile app, so whoever has the app can find it: payload encryption hides bodies from the network in between, it is no secret from your own users.
  • API Maker itself speaks plain HTTP. Run it behind Caddy or another proxy that serves HTTPS: API Maker Launchpad sets up Caddy, Ferron or Pingap.
  • Email codes need SMTP settings in the root user settings.

Questions

Do encrypted payloads replace HTTPS?

No. They add a second layer on top of HTTPS, useful when TLS ends before API Maker or when the body must stay opaque to intermediaries.

Who sets the two-factor policy?

The root user: email codes, authenticator codes, recovery codes, code length and expiry, attempts and resend delay.

How do I report a vulnerability?

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