Hey there 
Just wrote a Twitter thread explaining how to secure a web app in 4 steps.
I’d love your feedback on it because it will help me write an article and record a video on the topic for the soon to be released Weweb blog and Weweb academy 
Is it helpful? Is anything unclear? Are you missing key information?
I think it’s really helpful and well done!
Awesome, clear, and informative thread.
I loved how you used screenshots and showed how the front-end, chrome developer tools, and the configuration in the no-code tools was all related.
My one recommended addition to your article is perhaps including a sentence or two about how to go about testing/auditing the security of your application after you’ve built it. For example, what type of person could you hire or service could you buy to run an audit/test on your system to check for these vulnerabilities?
Ooooh love that suggestion! Thank you, Wes 
I feel very useful and so clear!
Additionally, What is the best way to get user’s roles in frontend?
For example, I want to show a link to admin’s page only if the user is admin using supabase auth.
How can I easily get and check user’s roles?
Great question @IdeaGarage!
Assuming you’ve setup your Supabase like we did in this tutorial, you’ll be able to see a user’s role when they log in.
In the screenshot below, you see I have the “Customer” role:
You can then use that variable to check if the user has the “Admin” role or not. By binding the result to the display property, we hide the link to “Your fleet” page when the user doesn’t have that role:
But we display it when a user with the “Admin” role logs in:
Note that:
You still need to protect the “Your fleet” page by restricting its access to admins because the URL is still available in the current page’s source code
This formula is probably not the most elegant way of doing this because we’re counting on something to be undefined to make a decision but it works 
I’ll ask the devs on our team if they have a better solution!
Many thanks to you,Joyce! I really understood.
What about this code(no-code)?
toBool(lookup(“admin”,Supabase Auth - [‘user’][‘roles’],“name”))
By the way, Private access with user groups is only capable in Scale plan… I think these feature are quite basically in the test phase, so I should have created another workflow to check whether the user is Admin or not. (Already capped by access volume, so Starter plan should not to be restricted other points, for the developers and WeWeb growth, I assume)
We’re currently working on a new pricing plan. I’ll pass your suggestion along!
Awesome, very important subject and one that needs to be at the forefront of every low code project. Great post!
Agree on this topic as well!
@Joyce this thread was excellent.
Combined with Chris Coleman’s recent Xano tutorial about securing your APIs, I finally feel a sense of relief about applying security measures to my application.
Here is a link to his tutorial:
I think a very basic thing that most people might miss out: Don’t use your private keys for an API call in the frontend (Like Stripe, Airtable, Slack, etc).
Instead, call your backend, and use that to call the 3rd party service. Otherwise, your private keys become exposed
Chris is really rocking it lately
Awesome, thanks for sharing!
What I’m very surprised not to seen explained is how we are supposed to protect our Xano API endpoints.
You see, when creating a Collection on WeWeb, we can’t set any headers along the request that’ll be made to Xano.
This means we cannot incorporate some kind of security key (token) to identify our WeWeb app as being the source of the request.
In this example, how are we supposed to secure the /user GET endpoint? It should be behind authentication, but WeWeb needs it to be public to fetch the data.
I don’t see many solutions, because we don’t have access to headers.
On Xano, we might be using headers to filter out domains where requests are allowed, but it’s clearly not enough.
I’ll watch the rest of Chris’s video, maybe I’ll catch something I missed…
After watching the video (which is great, indeed), I don’t see how any current WeWeb user can properly secure the API endpoints that are used by WeWeb to fetch collections, due to the lack of Headers configurability.
I think this needs to be addressed ASAP.
My clients won’t accept to use WeWeb if something as basic as that isn’t handled, and it shows very bad security practices.
The “API Key” we set in WeWeb is only used to list our Xano account endpoints, it doesn’t seem to be used when fetching Xano collections.
What I was missing (and isn’t explained anywhere when setting up authentication), is that we need to authenticate as a user, in the editor from WeWeb to make the “Collection fetch” work again, after having enabled the authentication on Xano endpoints.
That was what I was missing, I didn’t understand WeWeb was using the currently authenticated user to perform requests related to collection, I thought it had its own internal fetching mechanism (like Stacker and Noloco do).
So, it is possible to secure our Xano endpoints, assuming we authenticate as a user.
Which isn’t always what we need to do! I’m glad my current use case is compatible with this behavior, but I wish I had the ability to configure Request Headers when configuring WeWeb collections, so that some collections wouldn’t be related to the current user (no need for the user to be authenticated) and yet ensure the Xano endpoint is not public.
I hope Request Headers are soon implemented in WeWeb, because a lot of use-cases aren’t yet safe.
If there is no need for the user to be authenticated, doesn’t this mean that the endpoint is public? 
You can enable authentication on the Xano endpoint to make sure that only authenticated users have access to the endpoint, without the endpoint returning content that is related to the user.
And you probably figured that out by now but you do need to add the Xano Auth plugin to authenticate your users and add their authtoken to requests.
If the current Xano plugins don’t provide enough flexibility, you can always use vanilla REST endpoints (with the REST plugin).
If there is no need for the user to be authenticated, doesn’t this mean that the endpoint is public?
Not necessarily. If “Public” means “anyone can query the endpoint and get things done”, then there are other ways that Xano Authentication to protect endpoints.
The Xano “Authentication” is only one way, another way (which is what I used) is to check a token value contained in the Request Headers.
Although Xano will display the endpoint as “public”, it’s not really public, and that a valid way to protect endpoints from abuse, it’s as secure as the built-in Xano “Authenticated” option.
Gotcha, that makes sense!
Until we can modify the headers in the no code interface, here’s the component code (open source), which you can always interact with: GitHub - weweb-assets/plugin-xano
