I've been learning about web security, here are some tips applied to no-code. (most backend, some frontend)

DISCLAIMER: I'm not a security expert at all, so takes everything I say here with a gram of salt and do your own research!

Apart from securing your endpoints with security measures (like Xano Auth Tokens), I found some other concerns you may have when building webapps.

The easy and basic (no-brainer recommendations):

Xano automatically builds CRUD operations (without authentication) for each table you create. Unless you need them, turn that option off (on the new table menu). If you don't, anyone with your Xano URL (which may be obtained from your frontend) can call them (guessing the table name, such as "user" or "payment" or "property" or whatever you called them) and do funny stuff like read all your records, use the ids to delete them, or edit them, or create new ones without any of your logics.
Unless you need them to be public, hide all your API docs; same as the past example. If someone has your XANO URL, and you don't turn off your API docs, they have a guide on how to call your APIs on your behalf. This is especially concerning if you don't set authentication for each API that does sensitive stuff, which takes us to the next tip.
Secure all your endpoints that return info or do sensitive operations on your backend, but more than that, only return info to an auth token about the id saved inside the auth token. For example, if you have an API that returns the property of a user, don't query by a given user_id on the JSON body, but by the user_id stored on the authtoken! Xano uses JWT encoded tokens, which means that the auth tokens can contain info, and they contain the id of the user by default, so ALWAYS query by that. If you don't, anyone with an authtoken can trigger APIs on behalf of other users just by changing the user_id on the JSON body.
Encrypt any sensitive data on your db (such as card numbers, or user identification documents, etc.), or even better, don't save any sensitive data at all. Research if you can make that save payment method process without actually saving the user card details, the majority of vendors (such as Stripe) allow you to handle tokens that represent user payment data, but they handle the actual payment data (and more than probably, they are better at doing so).
Be careful with how you save the authtoken on the frontend and give each token a short life (I think the default 1 day is ok for most, but depending on your project, you may require longer or shorter).

Now, the more complex stuff:

As you know, on webdev we have different major concerns, but I believe the most important ones (apart from the above) are; Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).

Cross-Site Scripting refers to allowing a user to input JS scripts inside of user inputs, and then executing them on other users' browsers. For example, say you build a blog, and allow the user to type whatever they want. If the user types a JS script tag in the body, and you don't sanitize it, it will run this JS on every user that accesses that blog, which may result in data leaks (including authtokens if saved in the session storage).

This can be solved by sanitizing each user input on the frontend (I know Webflow and Wized do so) and performing input type validations on the backend (Use Xano input type for that, or preconditions if you prefer). Xano automatically helps with this and SQL Injection by escaping the data. It's also crucial to properly encode output when displaying user-generated content.

CSRF is kind of more complex to explain, so I'll just link a video for that: Cross-Site Request Forgery (CSRF) Explained - YouTube

What you need to know is: CSRF can happen when you save the authtoken inside the cookies of your website without the proper security flags (which are hard to implement on no-code tools). Storing tokens in session storage will prevent CSRF, as these tokens aren't automatically sent with every request like cookies are. However, session storage is still vulnerable to XSS attacks, so try mixing those two.

If you're handling really important forms, I highly recommend you use anti-CSRF tokens, but that's quite a hard implementation, and I feel it's quite an overkill for the majority of no-code projects.

Please feel totally free to correct me if I'm wrong in anything, I'm not a security expert at all, so take everything I said with a grain of salt and do your own research!

4 comments