Zite Security Guide: Roles, Workflows and Data Permissions

Quick answer: A Zite app is safe for production once every table has the right roles and data permissions, every workflow checks its caller and validates inputs on the server, and no secret reaches the browser. Here is how to check each one before launch.

By Paula C · Kraftwire Software

· 6 min read

A Zite app is safe for production once three things are true: every table has roles and data permissions that match who should see each record, every workflow checks who is calling it and validates its inputs on the server, and no secret ends up in what the browser downloads. This guide walks through each one, and shows what a SimplyScan scan can and cannot check from outside.

Zite is an AI app builder for business software. You describe what you need, and it builds apps, workflows, forms and portals on top of a shared Zite Database. In April 2026 Zite announced an agreement to acquire Raydian's IP, and the Raydian product is being shut down, so if you were building on Raydian, Zite is where that work now continues.

How a Zite app is put together

Knowing the pieces tells you where the security decisions live:

  • The Zite Database. One database per project, shared by every app, form and portal in it. A mistake in one table's permissions affects every app that reads that table.
  • Workflows. Your backend logic. Workflows read and write data, send emails and Slack messages, call APIs and run AI steps. Each one your app calls is a server endpoint, and anything a browser can call, an attacker can call directly too.
  • Access. Apps can require login. Users are split into editors, internal app members and external users, and roles and data permissions decide who can view, create, edit or delete records. Zite also offers field permissions and audit logs.
  • Publishing. The Publish button pushes changes live on a Zite link or your own domain, and Share to web takes an app offline.

The 5 checks to run before you launch

1. Set data permissions on every table

Login answers "who is this?". Data permissions answer "may this person see this record?". An app can have perfect login and still show every customer's orders to every signed-in customer.

The fix: For each table, decide which roles may view, create, edit and delete, and whether a user should see only their own records. Use field permissions for columns like internal notes or pricing that some roles should never see. Then sign in as two different test users and confirm neither can see the other's records. Our broken access control checklist has a step-by-step version.

2. Make every workflow check who is calling it

A workflow is only as safe as the checks inside it. If a workflow takes a record ID from the browser and updates that record without checking the owner, any signed-in user can change anyone's data by sending a different ID.

The fix: In every workflow that touches user data, take the user's identity from the session, never from an input field, and filter reads and writes by that owner. Never let a request change who owns a record.

3. Validate inputs on the server

Form validation in the browser is for user experience. Anyone can skip it and call the workflow directly. When we built our own Zite test app in October 2026, an endpoint's declared input schema was not enforced at runtime until we added explicit parsing at the start of the endpoint.

The fix: Parse and validate every workflow input on the server before it reaches the database: type, length, format and allowed values. Then test it by sending a request with a missing field and one with an oversized value.

4. Keep secrets out of the browser

API keys for OpenAI, Stripe or other services belong in server-side configuration that only workflows can read. Anything placed in page code is readable by every visitor.

The fix: Keep keys in workflows and integrations, never in client-side code. Use the SimplyScan secret scanner on anything you are unsure about, and rotate any key that was ever exposed. Our environment variables guide explains why.

5. Check what is public on purpose

External portals and public forms are meant to be reachable without login. Make sure that is a decision, not a default.

The fix: List every app and portal that is shared to the web, and every table it can read. For each one, confirm that an anonymous visitor sees only what you meant to publish. Take apps you no longer use offline.

What a SimplyScan scan checks on a Zite app

Run a free scan on your app's URL. The SimplyScan Security Engine recognises a Zite app from its Zite link or from the Zite SDK in its code, and then checks what is visible from outside:

  • Exposed secrets in the page and its JavaScript.
  • Security headers, SSL and the rest of the site health report: speed, SEO, AI visibility, accessibility, GDPR signals, domain and email security.
  • Backends and app API routes it can see in the code, tested for data anyone can read without signing in.

What it does not do is guess. Zite's own record permissions and workflow authorization can't be seen from a public URL, so the report shows them as unverified instead of marking them as passed. Checks 1 to 3 above still need you, or a test with your own signed-in test users.

Summary

  • Set roles and data permissions on every table, and test them with two users.
  • Take the caller's identity from the session in every workflow, and filter by owner.
  • Validate every workflow input on the server.
  • Keep keys in workflows, never in page code.
  • Publish to the web only what you mean to.

Related Resources

Frequently Asked Questions

Is Zite safe for production apps?

Yes, when its permissions are set up correctly. Zite gives you roles, data permissions on records, field permissions and audit logs, but they protect your data only if every table and workflow uses them. Test with two separate users before you launch.

What happened to Raydian?

Zite announced in April 2026 an agreement to acquire Raydian's IP, and the Raydian product is being shut down. Apps you build on Zite should follow this guide.

Do Zite workflows need their own security checks?

Yes. Every workflow your app calls can be called directly, outside your app's screens. Each one should check who the caller is, act only on that user's records and validate its inputs on the server.

Can SimplyScan test my Zite app's permissions?

A SimplyScan scan checks what is visible from outside: exposed secrets, security headers and any backend data readable without signing in. Zite's internal record permissions and workflow authorization aren't visible from a public URL, so the report marks them as unverified rather than guessing.

How do I scan a Zite app?

Enter your app's URL at SimplyScan. The free scan takes about 30 seconds and needs no sign-up.

Frequently asked questions

Is Zite safe for production apps?

Yes, when its permissions are set up correctly. Zite gives you roles, data permissions on records, field permissions and audit logs, but they protect your data only if every table and workflow uses them. Test with two separate users before you launch.

What happened to Raydian?

Zite announced in April 2026 an agreement to acquire Raydian's IP, and the Raydian product is being shut down. Apps you build on Zite should follow this guide.

Do Zite workflows need their own security checks?

Yes. Every workflow your app calls can be called directly, outside your app's screens. Each one should check who the caller is, act only on that user's records and validate its inputs on the server.

Can SimplyScan test my Zite app's permissions?

A SimplyScan scan checks what is visible from outside: exposed secrets, security headers and any backend data readable without signing in. Zite's internal record permissions and workflow authorization aren't visible from a public URL, so the report marks them as unverified rather than guessing.

How do I scan a Zite app?

Enter your app's URL at SimplyScan. The free scan takes about 30 seconds and needs no sign-up.

Related guides

  • Bubble Security Guide: Privacy Rules, API Tokens, and Data Exposure · Bubble apps are not secure by default. Without privacy rules, your database is publicly accessible via the Data API. To secure your app, you must implement Row-Level Security, protect 32-character API tokens, and authenticate backend workflows. SimplyScan's free audit helps detect these risks in ~30 seconds.
  • FlutterFlow Security Guide: Firebase Rules, Auth, and Data Protection · FlutterFlow apps are secure only if you manually configure Firebase Security Rules, restrict API keys, and enable App Check. By default, these apps often ship with permissive rules that expose your entire database. You must replace 'allow-all' logic with ownership checks and move sensitive API logic to Cloud Functions to prevent data breaches.
  • Base44 Security Guide: Critical Vulnerabilities and How to Protect Your App · To secure a Base44 application, you must manually configure the entity permissions panel for every database table and move all secret API keys to server-side environment variables. Implementing Row-Level Security (RLS) and server-side authorization guards is critical to prevent unauthorized data access and account takeovers.
  • Bolt.new Security Guide: 7 Vulnerabilities to Fix Before Launch · Bolt.new apps often ship with critical flaws like API keys bundled in client JavaScript and missing Supabase RLS policies. To secure your app, move secrets to server-side functions, scope RLS to auth.uid(), and enforce server-side authentication. SimplyScan finds these vulnerabilities in 30 seconds, helping you ship safely.

All security guides · Free security tools · Platform scanners · Security checklist