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.
See it live
Step through it, slow it down, or open the full canvas.
api-maker/features/securityLive- 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
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.
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.
A captured request expires.
The payload carries its creation time. Sent again after feTransferDataValidityInSeconds, 300 seconds here, it is refused: Payload expired.
The answer can go back encrypted.
x-am-get-encrypted-data asks for the answer in encryptedData, alone or next to data.
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.
Packages checked for known vulnerabilities.
The vulnerabilities page audits the packages of API Maker and the npm packages you add to your sandboxes.
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.