Xano API Penetration Testing

Every Xano endpoint runs on its own function stack, the sequence of steps that decides what data reaches the response and who is allowed to trigger it. What that stack checks, and in what order, is what actually gates access, not the interface built on top of it.

The function stack decides what an endpoint checks and returns, not the frontend calling it

Creating a database table in Xano can generate a full set of CRUD endpoints in one click, and Xano’s own security guidance confirms these ship with no authentication required and External Access enabled by default, which is convenient while prototyping but a risk if it survives into production. The toggle that closes this gap sits in each endpoint’s own Settings panel, where authentication can be required against whichever table has the function enabled, typically the user table. Endpoints created early in a build and then forgotten, sometimes called ghost endpoints, stay live and reachable long after anyone remembers building them. We audit every API group for endpoints left this way, and check whether the workspace’s Swagger documentation is still public and non-tokenised in production, since that setting publishes a directory of every endpoint in one place.

Authentication in Xano runs on JWE (JSON Web Encryption) tokens, generated by the Create Authentication Token function from a user id, an optional extras payload for data such as a role, and an expiration in seconds that a builder can set to a very large number if they never want the token to expire. A signed-in token proves who is calling an endpoint, but on its own it does nothing to stop that caller passing someone else’s record id, so every query and edit still needs its own filter or precondition against the authenticated user’s id, typically written as an expression such as items.user_id = auth id. Where a role is checked from extras rather than looked up fresh from the user table, that role is fixed at the moment the token was issued, so a change to a user’s role after login will not reach a function stack still reading the old token. We test the tokens themselves, the endpoints an unexpired or non-expiring token can still reach, and whether every path to a record, not just the obvious one, applies the same ownership and role checks.

External API calls from a Xano function stack go through the External API Request function, and the keys those calls need are meant to live in workspace-wide environment variables rather than typed directly into a header or a database column. On the response side, Xano’s own documentation confirms that building visually will automatically return the output of the first variable in the stack, so a Query All Records left as the last step returns every field on every matching record, not just the ones a frontend needs. Xano also applies a default wildcard CORS policy to API groups, and its own guidance recommends replacing that wildcard with an explicit list of allowed origins, methods and headers before launch. No-code frontends add their own wrinkle: WeWeb’s Xano plugin forwards authentication tokens automatically once configured, while Bubble’s API Connector and FlutterFlow’s API Call feature are set up by hand against the same Swagger documentation, so a header, scope or token copied in once during setup can go unreviewed long after the endpoint it points to has changed. We test what a function stack leaks through external calls or error messages, what a default response exposes, and whether CORS and every builder’s saved configuration still match what the endpoint allows today.