Xano runs the backend for a large share of Bubble, FlutterFlow, and WeWeb apps: the database, the API layer, and the auth logic sit behind a visual no-code builder instead of a Postgres console you'd log into directly. That distance is exactly where the risk hides. Xano does not run automatic row-level security the way Supabase does. Every endpoint that touches user data needs a manual check, or it hands back every row in the table to whoever calls it.
TL;DR
Xano's platform security is solid: SOC 2 Type II, ISO 27001, GDPR, and HIPAA certifications are available, with TLS 1.2+ in transit and encryption at rest on passwords and stored data. The gap is architectural. There is no database-wide row-level security. You add a precondition or an auth.id filter to each endpoint individually, and forgetting one on a single "quick" endpoint exposes that table's full contents. RBAC with custom roles is also gated to Pro and Custom plans; on lower tiers, every Developer you invite gets broad workspace access by default.
What Xano Controls (Platform Security)
Xano holds SOC 2 Type II, ISO 27001, and GDPR certifications, plus HIPAA support for regulated workloads. Passwords are hashed with SHA-256 and unique salts. All traffic runs over TLS 1.2 or higher, and stored data is encrypted at rest.
Hosting is available across more than a dozen regions, including the US, EU (Belgium, Germany, France), UK, Canada, and several APAC and Middle East locations, which helps with data residency requirements. Dedicated-resource and Enterprise plans add single-tenant deployment, which removes the noisy-neighbor and shared-infrastructure risk that comes with multi-tenant SaaS hosting.
None of that is unusual for a backend-as-a-service platform at this price point. It's table stakes. The differentiator is what happens once you start building endpoints.
The Missing Piece: Row-Level Security Isn't Automatic
Supabase and most Postgres-native platforms let you write a Row Level Security policy once, attach it to a table, and every query against that table gets filtered, no matter which API route triggers it. Xano works differently. Access control lives inside each individual API endpoint's function stack, not in the database.
The standard pattern is to filter by the auth.id variable, or add a precondition function that halts execution if a check fails:
precondition ($input.record.owner_id == $auth.id) { error_type = "accessdenied" error = "Not your record" }
That works, as long as you remember to add it. And that's the problem. Preconditions are opt-in per endpoint. Build a projects table with twelve well-guarded endpoints, then add a thirteenth "export all projects to CSV" endpoint six months later for an internal reporting feature, and if you skip the precondition on that one, it returns every user's projects to whoever calls it, authenticated or not.
There is no database-level policy in Xano that catches an endpoint you forgot to secure. Every new endpoint touching user data needs its own explicit auth.id check. Grep your API groups for endpoints without a precondition or auth.id filter before you ship.
This is a meaningfully different risk shape than Supabase's RLS-off-by-default problem covered elsewhere on this site. Supabase fails open at the table level; Xano fails open at the endpoint level. Auditing Xano means walking every endpoint in every API group, not just checking a table-level toggle.
RBAC Is Plan-Gated, Not Free
Xano ships five default, fixed roles at the instance level:
- Admin: full access to every workspace resource, release, and security setting.
- Developer: broad access to nearly everything except tenant-level RBAC, tenant secrets, and cluster management.
- Readonly: view-only across configuration, data, and logs.
- Billing: instance-level billing visibility only.
- Suspended: no access.
Custom, fine-grained roles built through the Permissions Center, the kind that let you scope a contractor to one workspace and one table, require a Pro or Custom plan. On the plans below that, your only lever is which of the five fixed roles you assign. In practice, that means the Developer you added to build one feature can see and touch nearly everything else in the instance too.
If you're on a lower-tier plan and need to bring in a contractor for one workspace, consider a separate Xano instance scoped to just that project instead of adding them as Developer to your main instance.
Change History: Scale Plan or Higher
If a teammate or contractor edits an endpoint's logic and something breaks in production, can you see who changed what and when?
Xano's Compliance Center logs every alteration to a workspace object (database tables, schemas, API groups, endpoints, background tasks) along with the team member, timestamp, and branch. It's available on Scale plans and above. Below that tier, there's no built-in change history. Your only fallback is Xano's version control and branching features, which snapshot state but don't attribute who changed what.
If you're running production traffic through Xano and multiple people touch the backend, the Compliance Center is worth the plan upgrade on its own.
Xano vs. Supabase: Data Access Model
| Aspect | Xano | Supabase |
|---|---|---|
| Data access control | Per-endpoint precondition / auth.id filter | Database-level RLS policy |
| Default state on new table | Open until you add checks | Open until RLS is enabled |
| Scope of a missed check | One endpoint leaks that table | One table leaks to every caller |
| Custom RBAC | Pro / Custom plan | Postgres roles (any plan, self-managed) |
| Change history | Scale plan and above | Postgres logs / self-managed |
| SOC 2 Type II | Yes | Yes |
Neither model is inherently worse. Postgres RLS is more foolproof once configured correctly but has a steeper setup curve. Xano's precondition model is simpler to reason about endpoint by endpoint, but it puts the burden on you to remember every single time.
Is Xano safe for production apps?
Xano's platform security is solid: SOC 2 Type II, ISO 27001, GDPR, and HIPAA certifications are available, with TLS 1.2+ in transit and encryption at rest. The risk is architectural rather than organizational. Xano has no automatic row-level security. Each API endpoint needs an explicit precondition check against auth.id, and skipping it on even one endpoint exposes every row in that table to any caller.
Does Xano have row-level security like Supabase?
Not in the same sense. Supabase enforces RLS policies at the Postgres database layer, so every query is filtered no matter which endpoint runs it. Xano's data protection lives in the individual API endpoint's function stack: you filter by the auth.id variable or add a precondition function per endpoint. There is no database-wide policy that catches an endpoint you forgot to secure.
What is Xano's RBAC and who can use it?
Xano ships five default roles: Admin, Developer, Readonly, Billing, and Suspended. Admin and Developer permissions are fixed and cannot be edited. Custom, fine-grained roles through the Permissions Center require a Pro or Custom plan. On lower plans, anyone you add as Developer gets broad access to nearly every workspace resource except tenant-level RBAC and secrets.
Does Xano log who changed what in my backend?
The Compliance Center, which records every change to a workspace object along with who made it and when, is available on Scale plans and above. Below that tier, you cannot pull a change history if a teammate or contractor modifies your backend logic.
What is a precondition in Xano and why does it matter for security?
A precondition is a function-stack step that halts execution and throws an error if a condition is not met, for example checking that a record's owner_id matches auth.id before returning it. It is Xano's primary tool for enforcing per-user data access. Because it is opt-in per endpoint rather than a database-level policy, every new endpoint you add needs its own precondition, or it silently returns unfiltered data.
Building on Xano?
Scan your app for endpoints missing auth checks, exposed API keys, and other issues before a stranger finds them first.