Xano security checklist

Xano Security Best Practices

Xano provides the infrastructure for your app. You are responsible for setting up authentication, permissions, and the logic that protects your data.

We offer Xano security audits to check your application for security issues. These can include a WeWeb audit.

1. Authentication

API authentication ensures that only users with a valid “token” can access private data. This is the most fundamental security step, yet it is often overlooked during initial development.

Don’t wait: Secure private endpoints from the start.
How to set up: Navigate to API -> Settings -> Authentication to configure your provider.

2. CORS Settings

CORS (Cross-Origin Resource Sharing) is a browser security feature. It prevents a website at one domain from making requests to a server at a different domain unless specifically permitted.

Why it matters: By controlling the allow-origin header, you ensure that only your specific front-end (e.g., myapp.com) can call your API.
Note: CORS only affects browser-based requests. It does not restrict server-side calls (like a Xano-to-Xano request).
How to set up: Go to your API Group -> More options -> CORS Management.

3. UUID vs. Integer ID

A UUID (Universally Unique Identifier) is harder to guess than a sequential Integer ID.

The Security Benefit: Sequential IDs (1, 2, 3…) are predictable. An attacker can easily “scrape” your database by simply changing the ID in a URL. UUIDs are random and nearly impossible to guess.
Trade-offs:
- Storage: UUIDs take 16 bytes; integers take 4.
- Performance: For large tables (hundreds of millions of records), UUID indexes can be slightly slower.
- Xano Storage: Larger indexes consume more of your “Database SSD Storage” quota.

4. Referencing User ID in API

When building “self-service” features (like a user updating their own profile), never use a user_id as an input parameter.

The Vulnerability: If your API accepts user_id as an input, a malicious user could change that number to someone else’s ID and modify their data.
The Fix: Always use auth.id (the ID embedded in the secure authentication token) to identify the user making the request.

5. Back-end Password Strength

Don’t rely solely on front-end validation for passwords. You can enforce complexity directly at the database level in Xano.

How to set up: Go to your user table -> right-click the password column -> set up the required filters (e.g., minimum length, special characters).

6. Consistent Error Messages

According to OWASP (Open Web Application Security Project) recommendations, your login and password reset flows should not reveal whether a specific email address exists in your system.

Bad Example: “Email not found” or “Incorrect password.” (Together these tell an attacker whether the email exists.)
Good Example: “Invalid email or password.”
Why: Generic messages prevent “user enumeration,” where attackers test lists of emails to see who has an account on your platform.

7. Access to Swagger Documentation

Xano automatically generates Swagger documentation (an interactive map of your API). While helpful for developers, it shouldn’t be public for production apps.

Configuration: You can restrict access to your Swagger documentation in the API Group Settings.

8. Role-Based Access Control (RBAC)

Apps with different user roles (e.g., Admin, Manager, User) need permission checks on each request.

Strategies for Checking Permissions:

Front-end Only (Worst): Never do this. Users can bypass front-end restrictions easily.
Query Every Call: Fetch user roles from the database on every API call. This is secure but can slow down your app.
Token Extras (Best for Performance): Encode the user’s role or organization ID directly into the JWE Authentication Token using “Extras.” You can access this data instantly without a database query.
Cached Functions: Use a cached function to store and retrieve user permissions temporarily.