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.
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 your npm packages for known vulnerabilities.
How it works
The origin is checked.
When your account has allowed origins, a browser request from any other origin is refused with 403.
Tokens and groups decide the call.
The API user token, the user token and their groups decide which API, table and fields the call can use.
An encrypted body is opened.
With x-am-encrypted-payload: true, the body is decrypted with the transfer key of your secret, and refused when it was made too long ago.
The answer can go back encrypted.
x-am-get-encrypted-data adds the encrypted response in encryptedData, alone or next to data.
What you get
Short replay window
An encrypted payload carries its creation time. Payloads older than feTransferDataValidityInSeconds are refused.
Allowed origins
List the web origins of your apps. Requests from other browser origins get 403 before anything runs.
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.
Package audits
The vulnerabilities page audits the packages of API Maker and the npm packages of your sandboxes.
Encrypted and hashed fields
Schema conversions store sensitive fields encrypted or as HMAC SHA-256 hashes, with the keys of your secret.
An example
A banking app
The mobile app encrypts every transfer before sending it, so the body stays unreadable even where TLS is ended by a proxy, and a captured request can not be replayed after a few minutes. Admin users need their authenticator app to sign in.
POST /api/schema/admin/bank/main/transfers/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.
common: <T.ISecretTypeCommon>{ encryptionAlgorithmFETransfer: 'AES', secretFETransfer: '…', feTransferDataValidityInSeconds: 300, // older payloads are refused},Good to know
- API Maker itself speaks plain HTTP. Run it behind Caddy or another proxy that serves HTTPS: the installer sets up Caddy.
- 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.