As far as I understand, WeWeb runs all it’s requests to the backend (Xano in my case) on the client side - correct me if I’m wrong.
This means all the requests WeWeb makes are interceptible in your web browser and, as far as I understand, there’s no way to prevent someone from replicating these requests from another client.
This raises a few questions for me (which I know aren’t exactly unique to WeWeb but more web development in general).
In short: How can you prevent someone from misusing an endpoint?
I’m aware authentication needs to be happening in the backend as well as the frontend. But surely that still leaves lots of opportunities for misuse.
A few I can think of:
Spam endpoints that don’t need authentication with bogus data. For example, you can’t require authentication for the sign-up endpoint so someone could spam hundreds of accounts.
Spam endpoints that do require authentication - just login first and then you can do whatever you like.
So what am I missing? What’s the established best practices around this?
For spamming, you can implement Captchas such as Cloudflare Turnstile which is free and for which I created a component in the marketplace. It basically gives you a code (client side) after verifying you’re not a robot (spammer), then you can verífy that this token is legit by calling Cloudflare’s API with a secret and the token from the frontend.
Thanks again @Broberto. It might make sense to protect some endpoints behind a Captcha (like sign-up), but you realistically couldn’t do this for every endpoint without creating very awkward UX.
So the other endpoints, do you just hope for the best?
I was hoping there might be some way Xano could be configured to only allow requests from WeWeb.
Surely this would make any app really easy to reverse engineer too?
You can use invisible captchas which do not require interaction, for public facing stuff. Or simply implement rate limiting for things where Captchas don’t make sense.
@mal There is no “bullet” proof prevention of public API endpoints. This has nothing to do with WeWeb; it’s how web apps work. You can do various things to mitigate the potential impact (like the captchas or rate limiting) but there is no 100% solution.
There are a few of ways to address this. One is cross-origin resource sharing, or CORS management. Xano has support for this built-in. Essentially if Xano doesn’t get a header that shows this comes from your weweb app, it won’t process the request. But its limited - basically someone can put in a bit of work, send the referrer header, and be done with it.
Another way is anti- cross-site resource forgery (CSRF) tokens. These are a little more complicated to implement but do a good job. Basically they require you to make a request of a certain kind to the server (in this case Xano) which Xano can then validate before responding to your query. It can do this validation at say the middleware layer to reduce the complexity on that end. But making a request from Weweb gets a little more complicated since you have to manage this token. This complexity is also beatable, but a lot more work to do so. Cloudflare turnstile and recaptchas are variants on the CSRF concept.
Finally, Xano itself can detect the IP of a request, which allows you to implement rate limiting on that side, which a spammer really dislikes because it means they can’t get data very quickly. Again this is beatable with a zombie network, but a lot of resources.
Depending on the nature of the resources you are guarding and the motivation and sophistication of your potential attackers, one or more of the above might serve you!