Custom App Security: How Your Code Is Protected

Code Storage Security

Your custom app's PHP code goes through two encoding steps before it is written to the database. First, the code is processed with HTML entity encoding, which converts characters like angle brackets, quotes, and ampersands into their safe HTML entity equivalents. This prevents the code from being interpreted as executable content if it is ever displayed in a web context. Second, the encoded result is converted to base64, which transforms it into a plain alphanumeric string that can be stored safely in any database field without risk of injection or corruption.

This double encoding means that your code exists in the database as an opaque text string, not as executable PHP. There is no way for a database read operation to accidentally trigger code execution. The code is only decoded through the platform's controlled loading process, which happens inside the application runtime after proper authentication and authorization checks have passed.

The encoding also protects against a class of attacks where malicious content in database fields could be used to inject code into other contexts. Because the stored code is fully encoded, it cannot interfere with database queries, HTML rendering, or any other system that reads the field value. The decoding happens only at the moment of execution, inside an isolated runtime environment.

Runtime Execution Protection

When your custom app's code needs to run, it is decoded and executed through a controlled function called safe_eval. This runtime environment provides the same execution capabilities as built-in apps, with access to all platform functions, but adds protections that limit what the code can do outside of normal operations.

The safe_eval function acts as a boundary between your custom code and the server environment. Your code can call platform functions like database reads, AI queries, and email sending because those are part of the intended feature set. But the runtime prevents operations that could compromise the server or other users' data. This is the same approach used by the platform's custom function feature, which has been tested across many users and applications.

Every time a request triggers your custom app, the platform follows a strict loading sequence: authenticate the request, load the app configuration, decode the PHP functions, and execute the specific function that handles the requested command. If any step fails, the request is rejected before your code runs. This means your code only executes in a fully authenticated, properly configured context.

API Access Control

Every API request to your custom app goes through the platform's standard security validation before your code executes. This validation includes multiple checks that must all pass:

• API key authentication where every request must include a valid API key that matches the account. Requests without a key or with an invalid key are rejected immediately.
• IP allowlist validation where you can restrict API access to specific IP addresses. If an allowlist is configured, requests from unlisted IP addresses are blocked even if they have a valid API key.
• Active app verification where the platform checks that your account has the custom apps module enabled and that the specific app being called exists and is active.
• Credit balance check where the platform verifies that your account has sufficient credits to process the request before executing any code.

These checks happen in the main router before your custom app code is even loaded. An attacker who does not have your API key cannot reach your app's functions at all. An attacker who somehow obtains your API key but calls from an unlisted IP address is still blocked. This layered approach means that multiple independent checks must all pass before any custom code executes.

For webhook endpoints, the platform routes incoming requests through the mode handler, which identifies the target app and loads it in the same authenticated context. You can add validation logic inside your webhook handler to verify that incoming requests come from the expected source, such as checking a signature header from a payment processor or verifying a shared secret from a form service.

Data Isolation Between Accounts

All database operations in the platform use a partition key model where your account ID is the primary key for every record. Your custom app reads and writes data under your account ID, and it is structurally impossible to access another account's data through normal database operations. This isolation is enforced at the database level, not just the application level.

DynamoDB, the database service that stores all platform data, requires a partition key on every read and write operation. The platform passes your account ID as the partition key for all queries, so your app can only see rows that belong to your account. There is no query syntax that could bypass this, because DynamoDB physically partitions data by the key. Your data and another user's data do not even exist in the same storage partition.

This isolation extends to all data types: app records, conversation histories, contact lists, uploaded files, configuration settings, and custom app code itself. Every piece of data is tagged with an account ID, and every operation filters by that ID. Even if your custom app code contained a bug that tried to read unexpected data, the database would only return rows matching your account's partition key.

Infrastructure Security

The platform runs on Amazon Web Services (AWS), which provides the foundation for all security measures. AWS infrastructure includes physical data center security, network isolation, encryption at rest and in transit, and compliance with major security standards.

At the network level, all communication between users and the platform happens over HTTPS. This encrypts every request and response in transit, preventing eavesdropping or tampering. The HTTPS requirement applies to API calls, admin panel access, webhook endpoints, and every other interaction with the platform. There is no option to use unencrypted HTTP for any production traffic.

The platform deploys on both EC2 (traditional servers) and AWS Lambda (serverless functions). Both deployment methods use the same codebase and the same security checks. Lambda functions run in isolated containers that are created fresh for each execution, which provides an additional layer of isolation between requests. EC2 instances are configured with security groups that restrict network access to only the ports and protocols needed for operation.

DynamoDB, the database service, encrypts all data at rest using AWS-managed encryption keys. This means your custom app code, your application data, and your configuration are all encrypted on disk. Even if someone gained physical access to the storage hardware, they could not read the data without the encryption keys managed by AWS.