Access Security

Access Security helps protect Cloud Flow workflows and the Project data or services those workflows use. Cloud Flow runs on the server, where it can perform trusted operations through the ioLoop Server API, Database, files, and configured Connections.

For Web Hooks, ioLoop provides an Access (Security) configuration that determines which callers may invoke the endpoint. The workflow's own logic must still decide whether the requested operation is authorized and valid.

Background Tasks are internal Cloud Flow modules. They are not exposed as Web Hook URLs and do not have the same Web Hook access configuration. Their logic, dependencies, and any helpers they make available through Flow Share must still be designed securely.

This guide covers the boundary between endpoint access, application authorization, Database permissions, external callers, and protected backend operations. For Web Hook methods, URLs, and responses, see Web Hooks.

Access Security vs. Authorization

A caller being allowed to invoke a Web Hook does not necessarily mean that every operation requested through that Web Hook should be allowed.

Layer	What It Controls	Example
Web Hook Access (Security)	Whether a caller may invoke a Web Hook under its configured access rules.	Restrict an administrative endpoint to the intended callers.
Application Authorization	Whether the particular action is permitted for the authenticated caller and target resource.	Allow a customer to update only an order they are permitted to manage.
Table Access	Which Database operations are available under the configured table access model.	Permit public registration creation without allowing public listing of registrations.
Business Rules	Whether the operation is valid under the current application state.	Reject registrations after an event reaches capacity.
Connection Security	How the backend obtains credentials for external services.	Use a configured payment or email Connection instead of browser-provided credentials.

These layers complement one another. A Web Hook may accept a valid request from a signed-in Project User and still reject an attempted change to another user's record.

The practical rule: Verify who may call the workflow, then independently verify what that caller may do.

Which Cloud Flow Modules Have Access Settings?

Module Type	Access Model
Web Hook	Has configurable Access (Security) settings because it can receive HTTP requests.
Background Task	Is an internal backend module; it is not a Web Hook and has no equivalent Web Hook access configuration.
AI Agent-related Cloud Flow	Operates within the relevant AI Agent and tool configuration; agent-related actions still require appropriate authorization.

Background Tasks can initialize timers, perform backend processing, or export helpers through Flow Share. They have no separate trigger or scheduling configuration: their behavior is determined by the logic implemented inside them. Module load order is not an access rule or a scheduler.

For module types and management, see Cloud Flow Types and Managing Cloud Flow.

Configuring Web Hook Access

A typical configuration workflow is:

1. Open the Project in the Project Editor.
2. Navigate to Backend → Cloud Flow.
3. Select the Web Hook whose access needs to be configured.
4. Choose Access (Security) from the module actions.
5. Review the available access choices and configure the intended callers using the options presented for the Project.
6. Save the access configuration.
7. Test an allowed request and a deliberately unauthorized request through the Web Hook's development test path.
8. Review the Cloud Flow logs and confirm the workflow returns an appropriate result without exposing protected data.

Use the actual access options shown in the editor. Do not assume that an access setting alone implements record ownership, request-signature validation, field-level restrictions, or every business rule.

For the meaning of Public, All Users, custom groups, Admin, and role levels, see User Groups. To create application identities, assign group membership, or manage Web Hook Keys, see Users.

Access (Security) is a separate module action from Settings. Web Hook Settings cover properties such as the name, HTTP method, and response streaming. The module's enabled or disabled state is also separate from its access configuration.

Choosing the Intended Callers

Consider who will use the Web Hook:

Caller	Security Considerations
Project Page or custom frontend	Decide whether the operation requires a signed-in Project User or particular User Group. Verify record-specific permissions inside the workflow where needed.
Public visitor	Permit only the operations intended for unauthenticated use; validate input and limit data returned.
External application acting as a Project User	Send that user's Web Hook Key in the HTTP Authorization header using the Bearer scheme. The user must be active and permitted by the Web Hook's access configuration.
External service	Use the provider's supported request-authentication mechanism when applicable, in addition to appropriate endpoint access and payload validation.
Another trusted backend workflow	Keep shared processing internal when an HTTP endpoint is unnecessary; apply explicit authorization if a Web Hook is used.

Do not make a Web Hook publicly accessible merely because it is easier to call during development. Conversely, a legitimately public workflow—such as a public request submission—can be designed safely when its permitted operations are narrow and protected by server-side checks.

Trustworthy Identity and Request Context

Cloud Flow can receive parameters, request bodies, headers, and other request information. Values supplied by a caller are inputs, not proof of identity or permission.

Treat these as untrusted unless independently verified:

• User IDs, email addresses, User Group names, or role labels in the request body.
• Record IDs, customer IDs, or ownership fields supplied by a Page.
• Hidden Form values and values generated by custom frontend JavaScript.
• URLs, filenames, status values, prices, quantities, or requested permissions.
• HTTP headers or tokens that have not been verified against the expected authentication mechanism.

For authenticated Project User workflows, use the supported trusted user or authentication context available to the backend, then check the relevant access conditions. Do not substitute a user ID asserted by the browser for verified identity.

An external application can authenticate as a Project User by sending the user's Web Hook Key as follows:

Authorization: Bearer PROJECT_USER_WEB_HOOK_KEY

When the key is accepted, the request is evaluated using the associated Project User's group memberships, role levels, and applicable Admin access. The key does not grant additional access or permission to bypass the Web Hook's Access (Security) configuration.

Keep Web Hook Keys out of request bodies, query strings, browser-delivered code, and logs. Manage them under Settings → Users and store them as secrets in the external calling application. For creation and rotation guidance, see Users — Web Hook Keys. For a complete request example, see Web Hooks — Calling as a Project User.

For other external callers, establish authenticity using the mechanism appropriate to the integration—for example, a provider's verified signature or credential when supported. An arbitrary header being present is not, by itself, evidence that the caller is authentic.

The exact request and authentication APIs are documented in the Cloud Flow Blocks and Server API references.

Authorizing Individual Operations

After the Web Hook is permitted to run, validate the particular request before performing consequential work.

A useful sequence is:

1. Validate the input. Check required values, types, ranges, and expected formats.
2. Establish the trusted caller context. Identify the signed-in user or verified external caller when the workflow requires one.
3. Retrieve the target resource. Load the record or resource needed to make the decision.
4. Check authorization. Verify ownership, User Group, permitted operation, or another application-specific condition.
5. Check business rules. Validate status, capacity, timing, or other conditions against current server-side data.
6. Perform the operation. Use the appropriate Database, file, Connection, or Server API capability.
7. Return a limited result. Tell the caller what happened without exposing unrelated records or confidential details.

The order matters. For example, an operation should not update an order before confirming that the requester is permitted to update that order.

Example: Updating an Order

Consider a UpdateOrderStatus Web Hook used by an order-management Page.

Receive request with OrderId and requested Status
  Validate input
  Establish trusted caller identity
  Load the requested order
  Check whether the caller may modify this order
  Check whether the status change is permitted
  If allowed:
    Update the record
    Return a limited success result
  Otherwise:
    Return an appropriate failure result

This is conceptual workflow logic, not a list of specific Cloud Flow block names.

The Web Hook should not trust a submitted IsAdmin, UserGroup, or OwnerId field to authorize the update. The relevant facts must come from an appropriate trusted source and the current record.

When several actions are involved, account for partial failures and repeated requests. Do not assume that multiple Database or external-service operations automatically form a single atomic transaction.

Frontend Access Is Not Backend Authorization

Page Flow, Forms, Widgets, and custom frontend JavaScript all run in the browser and can use the supported ioLoop Client APIs.

The built-in frontend features are convenient abstractions over those same Client APIs. They do not provide an additional privileged security boundary, and custom JavaScript is not inherently less capable than those built-in frontend components.

Frontend controls can improve the user experience:

• Hide an action that is irrelevant to the current user.
• Disable a button until input is valid.
• Show validation messages before submitting.
• Present records using a named query or filtered Widget.

However, none of these replaces protection of the underlying operation. A user may attempt to invoke an endpoint directly or change request values without using the intended Page.

Use Page Settings for Page access, Table Access for Database permissions, and Cloud Flow for trusted rules that require server-side enforcement.

Database Access and Cloud Flow

Cloud Flow uses server-side Database capabilities, including functionality available through the Server $io.db API that is broader than the browser-side Client $io.db API.

Server-side capability does not imply automatic authorization for every requested operation. Cloud Flow code is responsible for applying the intended application rules when it performs privileged or record-specific processing.

Before returning or modifying Database records:

• Verify that the caller may perform the requested operation.
• Confirm ownership, membership, or record-specific rules where relevant.
• Validate IDs and query inputs rather than trusting them as authorization.
• Apply status, capacity, and other protected business rules server-side.
• Return only the records and fields that the caller is permitted to receive.

Named Queries select data; they do not independently grant access. A query that accepts CustomerId does not prove that the caller may read that customer's records.

The Database access model, record-specific validation, and Cloud Flow endpoint access address different responsibilities. For details, see Table Access and Using Database from Cloud Flow.

File Fields and Access

Files associated with Database file fields inherit the access rules of their parent table.

If a table is publicly readable, files associated with records in that table must be treated as publicly accessible. Hiding a download button or omitting a file URL from the Page does not make the associated file private.

For sensitive attachments:

• Avoid storing them in a publicly readable table.
• Configure the relevant table permissions and test unauthorized access.
• Apply trusted record-specific authorization where the table permission alone is insufficient.
• Use appropriate private-file handling through supported Backend file operations when the workflow requires controlled distribution.

Do not assume that simply returning a download link after a Cloud Flow check protects a resource whose underlying storage is already publicly accessible.

For the complete model, see File Fields and Using Files.

Public Web Hooks and External Callers

A public Web Hook may be necessary for a public submission form or a third-party integration. Public access means the endpoint can receive requests from a broader set of callers; it does not mean every submitted operation should succeed.

Public Submission Workflows

For a publicly available request or registration endpoint:

• Accept only the data needed for that operation.
• Validate field types, required values, and reasonable input limits.
• Enforce current business rules on the server.
• Do not return private records or internal operational details.
• Consider how the workflow will handle automated abuse and repeated submissions.
• Apply an appropriate protection mechanism when the consequences justify it.

For example, a public registration endpoint may accept a new registration while refusing to list all registrations or update existing registrations.

External Service Web Hooks

For a payment provider or another external system:

1. Identify the provider's expected request format and authentication mechanism.
2. Verify the request using the provider-supported approach where applicable.
3. Validate the event or operation type before processing it.
4. Check whether the event was already processed when repeated delivery is possible.
5. Apply the intended trusted Database or external-service operation.
6. Return a response that matches the provider's documented expectations.

Some providers retry events or deliver them more than once. Design consequential operations to be safe against duplicates, and use persistent records when processing history must survive runtime restarts.

Avoid treating a difficult-to-guess Web Hook URL as authentication. For Web Hook configuration and HTTP behavior, see Web Hooks.

Connections and Protected Credentials

Cloud Flow can use configured Connections and integration-specific Server APIs for external services.

Prefer Connections over placing credentials directly in code or requests. Never send private credentials to browser-side Page Flow or include them in frontend Code assets.

When calling an external service:

• Verify that the caller is authorized to request the action.
• Use the appropriate configured Connection.
• Avoid returning access tokens or raw provider responses containing sensitive information.
• Handle provider errors without exposing secrets in user-facing messages or logs.
• Consider retries and duplicate effects for operations such as creating charges, sending notifications, or updating external records.

For implementation details, see Using Connections and Node.js Runtime and SDK Libraries.

Flow Share and Internal Helpers

Flow Share can expose runtime values and functions between Cloud Flow modules. Background Tasks commonly provide shared helpers because they load before Web Hooks and AI Agent modules.

Shared code does not remove the need for authorization. A helper that updates records should receive the trusted caller context and explicit operation inputs required for its checks, rather than assuming it has inherited the current Web Hook's identity or permissions.

Do not store permanent secrets or durable authorization state in Flow Share. It is runtime sharing, not persistent storage. See Flow Share.

Responses, Errors, and Information Exposure

Return information appropriate to the calling interface, not every detail available inside the backend workflow.

Outcome	Recommended Behavior
Authorized success	Return the information required for the caller's next step.
Invalid input	Return clear validation feedback without exposing sensitive implementation details.
Unauthenticated or unauthorized request	Reject the operation without revealing protected records or secrets.
Missing record	Return an appropriate result without disclosing more than the caller is allowed to know.
External service failure	Provide a useful failure status and retain technical diagnostics in protected logs.

HTTP response status and an application-level Result Object are different concepts. Configure the Web Hook's HTTP response appropriately and return a consistent result structure for the caller to interpret. The generated reference describes the specific response and Result Object blocks.

Avoid exposing raw errors, stack traces, Connection credentials, unneeded personal data, or entire Database records in responses.

Testing Access and Security

Test the actual invocation path, not only the Cloud Flow Editor. Include allowed and denied scenarios.

Test	What to Verify
Authorized Project User	A permitted caller can invoke the Web Hook and complete an allowed operation.
Project User Web Hook Key	A valid key is accepted only when its active user is permitted by the Web Hook's access configuration. Missing, invalid, and insufficiently privileged keys are rejected.
Unauthenticated visitor	Protected operations are rejected; legitimate public operations remain available.
Wrong User Group	The workflow denies an operation that requires a different group.
Other user's record	Record-specific checks prevent unauthorized access or changes.
Manipulated request values	Changing record IDs or asserted roles does not bypass authorization.
Public endpoint misuse	Invalid, oversized, unexpected, or repeated requests are handled appropriately.
External caller	Invalid credentials or signatures are rejected when verification is required.
Database permissions	Frontend access and trusted Backend checks enforce their intended responsibilities.
File attachment access	Restricted files are not exposed through a publicly readable parent table.
Backend failure	Errors provide useful feedback without exposing protected details.

Use the Cloud Flow development test runtime and Logs during testing. Test through Page Flow, custom frontend JavaScript, or the external caller as appropriate.

During Preview, ioLoop's built-in Database operations automatically use the development database. This allows Database-backed workflows to be tested without directing those built-in operations to production records. External Connections and other custom service operations may still have real side effects depending on their configuration; verify the environment before testing them.

When publishing, verify the live Web Hook access configuration and the behavior of the published callers. For details, see Testing and Logs and Previewing.

Troubleshooting Access Problems

Symptom	What to Check
Authorized Page cannot invoke a Web Hook	Web Hook Access (Security), enabled status, caller context, and development/published endpoint.
Unexpected caller can invoke a Web Hook	The configured access scope and whether the endpoint was intentionally made public.
Invocation succeeds but operation is rejected	Record ownership, User Group, business-rule validation, and supplied input values.
Sensitive data is returned	Query scope, response construction, field selection, and server-side authorization.
External service requests are rejected	The provider's authentication mechanism, request body or headers, and integration configuration.
Restricted file is accessible publicly	Parent table's Read permissions and the file storage/access model.
Different results in Preview and production	Development versus production records, published configuration, and external Connection modes.

Distinguish endpoint access failure from application-level authorization failure. A Web Hook can be callable while correctly refusing the particular action requested.

Good Practices

• Use least privilege. Give each Web Hook only the access required for its intended callers.
• Keep authentication and authorization separate. Establish a trusted caller context, then verify the requested operation.
• Validate at the server boundary. Treat Page Flow, custom frontend code, and external payloads as untrusted inputs.
• Use narrow Database operations. Retrieve and return only authorized records and fields.
• Keep secrets in Connections. Avoid placing credentials in browser code, request parameters, or logs.
• Protect file access through the data model. Remember that file-field attachments follow parent-table permissions.
• Design for repeated requests. Guard against accidental duplicate or replayed consequential operations where applicable.
• Test denial cases. Include deliberately unauthorized callers, modified inputs, and malformed requests.
• Revisit access after changes. A new Page, Agent, Integration, or external caller can change the workflow's exposure.

Common Mistakes

Avoid these patterns:

• Assuming Access (Security) automatically enforces record ownership or every business rule.
• Looking for Web Hook access controls or scheduler settings on Background Tasks.
• Assuming a hidden Button or restricted Page makes an exposed Web Hook secure.
• Trusting an ID, role, or group value supplied by the browser.
• Making a Web Hook public simply to simplify development testing.
• Retrieving broad datasets and filtering confidential records only in the browser.
• Treating a named query as an authorization policy.
• Storing confidential attachments in publicly readable tables.
• Returning raw backend errors, tokens, or complete records unnecessarily.
• Treating a successful call as proof that a protected operation was authorized correctly.
• Placing a Project User Web Hook Key in a URL, browser-delivered code, or logs.
• Assuming a Project User Web Hook Key replaces a provider's required signature verification.
• Testing only as an administrator or testing only successful requests.

Secure Cloud Flow design combines appropriate endpoint access, trusted authorization, Database permissions, careful handling of files and Connections, and deliberate business-rule enforcement.

Technical Reference

• Cloud Flow Blocks
• HTTP and Web Hooks Blocks
• Server API
• Result Objects
• Connections Blocks

Related Topics

• Cloud Flow
• Managing Cloud Flow
• Web Hooks
• Background Tasks
• Table Access
• File Fields
• Using Database from Cloud Flow
• Using Connections
• Testing and Logs
• Users
• User Groups